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ABSIR/VCI 



The SPLICE system is aesigasi ro integrate a variety of 
current and projectei NAVSU? processing and telecommunica- 
tions applications. The operation of the more than twenty 
new applications systems currently under development will 
increase the Navy's dependence on automated support, and 
will require that the risk of operating the SPLICE data 
processing environment be evaluated and managed at an accep- 
table level. This thesis identifies the requireraencs for 
implementing a Risk hanageraent Program, provides a formal 
model for the quantif icacion and management of risk, and 
examines contemporary technical and managerial countermea- 
sures which could be effective in reducing the operational 
risk of SPLICE. 
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I. BACKGaoaiJD 



A. IHTRODOCTION TO RISK HANAGESENT 



Computers have besoms an intagral part of the business 
and government world by perforaing many of the operations 
and applications that, in the past, were either done manu- 
ally or not at all. In addition to spending vast sums of 
money to acquire and operate computer hardware. Navy activi- 
s hc.v-5 d apol doTi. sod vcT"? 

development, ccmmu nic ation links for remote terminals and 
networks, site construction and daily operating expenses, 
and the administrative overhead of a dara processing depart- 
ment staff. More importantly, the proliferation of 
compu-ers has affected the day-to-day operations at a number 
of Navy acxivities. Many activities depend so heavily on 
their computers that if the computers ceased operation, 
eicher nhe activities would fail to accomplish their mission 
or they would suffer a severe degradation in rhsir mission 
effectiveness. 



The introduction of automation has resulted in a 
substantial increase in the risk an activity faces. ?or 
example, the centralization of data and services is often 
associated with a remote access capability. This added 

capability permits interrogation and alteration of data 
files with little or no check on the authenticity of the 
source. Additionally, there is often a reduction in the 
accessibility of visual records accompanying the shift to 
automated support. In a manual system, sales ledgers. 



payment 


books, and 


invoices are 


maintained 


by various 


internal 


departments 


to manage and 


monitor an 


activity ' s 


business. 


In a compu 


terized system. 


these same 


records are 
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re^ain-sd on magnetic storage aeiia and are updated automati- 
cally by a software program. The accuracy and authenticity 
of these records has become the joint responsibility of the 
data processing department and the user, which ofren results 
in uncertainty about the responsibility for data inregrity. 
The question is who is responsible for the data -- the user 
who originates the input and uses the result, or the data 
processing department, which has day-to-day responsibility 
for the automated processing. These new risks have gener- 
ated an obligation of management to protect this significant 
investment and to provide for continuity of operations 
should a catastrophe or accident occur. [Ref. 1: pp. 1-8] 

Protection can be accomplished by designing, developing 
and implementing countermeasures. These countermeasures, 
which can be either commerically procured or developed 
in-house by the activity, must prevent, minimize, or assist 
the data processing environment zo recover from any acci- 
dental or intentional unauthorized modification, 
destruction, disclosure, or denial of service. This process 
of safeguarding data processing assets is called automatic 
data processing (ADP| security. 

Perfect security is generally regarded as unattainable. 
Therefore, the objective of a good ADP security program is 
to reduce, for a reasonable cost, the probability of loss to 
an acceptable level and to provide adequate recovery in case 
of loss [Ref, 2: p. 2]. A good program can only be achieved 
by having t cp management ultimately responsible for the ADP 
security program and by applying quantitative techniques to 
determine how much protection is needed to reduce the risk 
of operating to an acceptable level. 

There are many approaches to help top management deter- 
mine the appropriate ADP security policy. The most endorsed 
approach uses risk management as the tool to develop and 
implement that policy. Risk management is a methodology for 



analyzing an environmant and dazarmining zha opzimal saz of 
countezmea sures neaiai to provide sufficient protecrion for 
rhat environmenr. 

The General Accounting Office (GAO) reports that 
risk management is an element of managerial science -.har is 
concerned with the identification, measurement, control, and 
minimization of impact of uncertain events upon organiza- 
tions that depend upon automated operations'* [Ref. 2; p. 35]. 
Robert H. Courtney, Jr., a pioneer of risk analysis tech- 
niques, says: 



Most management decisions involve the assumotion of 
risk — the chance that things may not turn out the way we 
hcoe or wane them to. Decisions mads in spire of uncer- 
tainties and, indeed, in recognition of them are 
generally accepted as essential no dynamic successful 
management. Most frequer.cLy, however, rhe key no 
success lies not in the willingness to acceo- uncer- 
tainry, or to assume risk. 6u- in the ability to 
recognize and quantify the elements of that risk so as 
to deal with them in a fully objective way. [Ref. 3: p. 



B. REQ0IR2MESTS FOR RISK MANAGEMENT 

Na V2 

The first federal raqulation that addressed data 
security and risk analysis was the Privacy Act of 1974. Two 
major concerns precipitated this law; the total amount of 
personal information maintained by Federal agencies, and the 
potential risk posed by the increasing use of computers and 
sophisticated information systems. The Act defines specific 
responsibilities to guarantee that personal information 
about individuals collected by Federal agencies is limited 
to that which is legally authorized and necessary and is 
maintained in a manner which precludes unwarranted 
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ir.*:rusions upon indi'/idua.i privioy. Th? Act requires each 
agency to establish apprapriate administrative, technical, 
and physical safeguards to ensure the integrity and confi- 
dentiality of personal inforaation and to protect against 
any anticipated threats or hazards which could result in 
harm, embarrassment, L nconveniea ce , or unfairness. [Ref. U: 
p. 133] 

When the Act oecame law on 31 December 197U, virtu- 
ally every agency in the Federal government was impacted. 
Because of its implementation responsibility, the Office of 
Management and Budget (0MB) was particularly affected. 0M5 
responded to the Act by issuing 0MB Circular No. A- 108, 
"Responsibilities for the Maintenance of Records About 
Individuals by Federal Agencies," dated 1 July 1975. 
Specific taskings associated with this circular are: 

• The National Bureau of Standards (NBS) is responsible for 
issuing standards and guidelines on computer and data 
security . 

• The General Services Aiminist r a.rion (G3Ai is responsible 
for revising computer and telecommunications procurement 
policies to ensure compliance with applicable provisions 
of the Act. 

• The (White House) Office of Telecommunications Policy is 

responsible for reviewing Federal agency policy on inter- 
connection and operational control of networks and 

communication security devices. [Ref. '4: p. 19] 

The Privacy Act of 1974 was the first in a series of 
events during the 1973 ‘s that focused national level atten- 
tion on the value and vulu erability of Federal data 
processing. Following the Act, in the spring of 1976, three 
GAO reports were published that brought congressional atten- 
tion to this growing concern and increased awareness of the 
potential risks facing the Federal ADP community. Shortly 
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ther ft<=r , senator Abraham Ribicoff directed the Committee 
on Government Operations to oonducr a preliminary inquiry 
in~o rhe problems of compurer securiry. The Coaimxrree 
subsequently issued two studies addressing the subject. The 
first report reviewed some of the major technological issues 
and problems identified by 3A3 and provided an extensive 
collection of articles written by experts in the field of 
computer security [Ref, 5], The follow-up report recom- 
mended that 0MB direct Federal agencies to put into effect 
appropriate computer security controls and safeguards, that 
NBS prepare physical and personnel standards for protecting 
Federal ADP systems according to their sensitivity, and zha.- 
Federal agencies improve coordination of computer resource 
protection efforts [Ref. 6: p. 276]. 

In response to these Congressional recommendations, 
OME issued Transmittal Memorandum No. 1 to Circular A-7 1 in 
July 1978 [Ref. 7]. In announcing this comprehensive 
Federal computer security program, 0MB Director James T. 
McIntyre, Jr., said, 

Ccmouter technoloay now impacts almost every facet of 
American life. The protection of the technology against 
unwarranted, unauti orized and illegal users ns a major 
challenge. This proaram addresses that challenge in the 
Federal Community. [Ref. 8] 

The Transmittal Memorandum requires each agency 
computer security program to satisfy the following 
requirement s; 

• Conduct a periodic risk analysis for each computer 
installation operated either in-house or commercially. 

• Assign responsibility for security to a management offi- 
cial knowledgeable in data processing and security 
matters , 
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» Establish a maaagament coat col process to ensure thar 
appropriate administrative, technical, and physical safe- 
guards are incorporated. 

• Ensure that appropriate security requirements are 
included in specifications for rhe acquisition or opera- 
tion of computer resources. 

♦ Establish personial security policies for screening all 



in dividuals 


parti 


ci pa ting 


in the design 


, operation, or 


maintena nee 


of 


or ha via 


g access to 


Federal computer 


systems . 










• Conduct peri 


odic 


audits or 


evaluations 


and recertify the 


adequacy of 


the 


se curity 


safeguards of 


each operational 



sensitive application. 

• Ensure that appropriate contingency plans are developed, 
maintained, and tested to provide fcr continuity of oper- 
ations should events disrupt normal operations. [Bef. 7: 
p. 3] 

Also in 1978, Presidential Directive Number 24 was 
issued which transferred the functions of the Nhite ^ouse 
Office of Telecommunications Policy tc the Department of 
Defense (DOD) and Deoartment of Commerce. DOD was tasked 
with telecommunications policy relating to national 
security. All other telecomnunications policy functions 
were assigned to the National Telecommunications and 

Information Administration under the Department of Commerce. 

Because DOD is the largest Federal agency in terms 
of personnel strength, budget sice, and number of computers, 
it is the most affected by the Federal policies discussed 
above. DOD reacted to 0MB Circular A-108 by publishing DOD 
Directive 5400.11 [Bef. 9]. This directive established a 
DOD Privacy Board with oversight review authority, and 

included guidelines for safeguarding personal data in ADP 
systems as an appendix. ODD approached Circular A-71 
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somewhat, less decisi/aly. Siri ::2 DOD had been involvei with 
the protection of classified data for years, it sought to 
apply the frameworK of A-71 to the existing classified arena 
and integrate the additional protection requirements for 
unclassified ADP systems. The objective of DOD was to 
develop an overall systematic concept to security that 
applied safeguards to each ADP system commensurate with the 
sensitivity of the data being processed. DOD forwarded the 
approach to 0MB in a memorandum dated 30 January 1980 and 
appropriately entitled '’A Comprehensive Information Security 
Program.” By the issuance of this memorandum, all military 
departments were taslxed to establish formal risk management 
and computer security programs as delineated in Ref. 7. 

In reaction to the proposed comprehensive DOD AD? 
Security Pregram, the Department of the Navy (DON) promul- 
gated OPNAVINST 5239.1, which assigned specific ADP security 
responsibilities within the Navy and established Designated 
Approving Authorities (DAA). The current version of this 
instruction [Ref. 10] directs each Navy activity to assign 
ADP security responsibilities, establish an Activity AD? 
Security Program, implement a formal Risk Management 
Program, and be accredited by the appropriate DAA. 

OPNAVINST 5239.1a, together with che Naval Material 
Command (NAVMAT) and the Naval Supply Systems Command 
(NAVSDP) i iplementati ons, should after a period of time 

substantially increase the protection afforded to DON ADP 
systems. The requirements for a Risk Management Program are 
summarized in Table I, which lists the regulations and 
reports published in the last decade. 

2* Ope rat iona l R a qu ir emen t s 

In order to establish and manage an Activity ADP 
Security Program, it is encumosat on activity top management 
(Commander, Commanding Officer, Officer in Charge, or 
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TABLE I 

Fed eral/D0D/D3 N Regulations on ADP Security 



197U 

^ 9'’5 



1976 



19"7 

1978 

1979 

1980 

1982 



Privacy Act of 1974 (Public Law 93-579) 



0MB Circular No. A-108, " Resoonsibilit ies for the 
Maintenance of Records about Individuals by 
Federal Agencies," 1 July 1975 

DODD 5400.11, "Personal Privacy and Rights of 
Individuals Regarding their Personal Records," 4 
August 1975 

NAVMATINST 5211.2, "Personal Privacy Act and 
Rights of ladividuals Ragardinq their Personal 
Records," 26 September 1975 



NAVSOPINST 52 11.1 t "Personal Privacy Act and 
Rights of Indiviauals Regarding their Personal 
Records (Privacy Act of 1974, Puolic Law 93-579) ," 
18 November 1975 



GAO Report, "Improvenent Needed in Managing 
Automated Deci sion making by Computers Throughout 
the Federal Government," April 1976 

GAO Report, "Computer-Related Crimes in Federal 
Programs," April 1976 

GAO Report t "Managers Need to Provide Better 
Protectncn ror Federal Automatic Data Processing 
Facilities," May 1976 

Senate Committee on Government Operations^ 
"Computer Aouses - Problems Associated witn 
Computer Technology in Federal Programs and 
Private Indust ry," “June 1976 

Senate Committee on Government Operations, "Com- 
puter Security in Federal Programs," February 1977 

NAVMATINST 5510.17, "Security of ADP Systems," 22 
March 1977 

0MB Circular No. A-71, Transmittal Memorandum No. 
1, "Security of Federal Automated Information 
Systems," 27 July 1979 

SECNAVINST 5211. 1C, "Personal Privacy and Riahts 
of Individuals Pertainina to Therr Personal 
Records," 4 December 1931 

DOD Memorandum, "A Comprehensive Information 
Security Program," 30 January 1980 



NAVSOPINST 5510.6A, "Security Requirements for ADP 
Systems," 28 May 1980 

OPNAVINST 523 9. 1A, "Department of the Navy 
Automatic Data Processing Security Program," 3 
August 1982 



j 
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Di rf^c*^or ) 


to imple 


men t a Risk 


Management Program. In 


the 


process of 


f or mali 


zing this pr 


ograin ^ 


top management 


rnus“ 


establish 


ADP S93 


urity policy 


with 


explicit regard 


to 


OPNAVINST 


5239. 1A 


and the 


unique 


requirements 


and 



constraints of the activity ADP systems. 'Ref. 10: p. 1-2] 

Since activities have invested heavily in computer 
resources, they often desire to maximize the utilization of 
their resources by sharing them among usees, both internal 
and external to the activity. Each user has a different 
need-to-know and neei- to-utilize criteria for accessing his 
information. This requires that individual user data 
integrity be assured, while concurrently providing shared 
access to the ADP system. For example, an ADP activity 
might furnish services to both fiscal and logistic users, 
each of which expects its asse-s to be protecred and avail- 
able upon demand. The task of simultaneously sharing and 
protecting an ADP system is the responsibility of the 
activity providing automated support. 

Ref. 10 requires xhat each Navy ADP activity be 
accredited for operational use. By accrediting an activity, 
the DAA, which in some cases is the activity Commanding 
Officer, acknowledges that the risk of operating the data 
processing environment is acceptable, in light of the activ- 
ity's mission and the users' dependence on automated 
support, and approves the system for operational use. To 
obtain accreditation, top management must quantify the oper- 
ational risk and implement an Activity ADP Security Plan. 
The Risk Management Program described in Ref. 10 and further 
explained by this thesis is the tool used by top mange ment 
to quantify the risk present, evaluate the cost- 
effectiveness of proposed countermeasures, and provide for 
recurring review of the activity's ADP security posture. 
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C, INTRODUCTION TO SPLICE 

Ths Stock. Foir.t Logistics Ir.tegrotsi Cotnmunics'^. ions 
Environment (SPLICE) is a NAVSJP Project designed -o inte- 
grate all interactive processing and telecommunications 
required by current and projected applications systems 
operating within the Uniform Automated Data Processing 
System for Stock Points (3ADPS/3P). The SPLICE Project will 
use standard minicomputers and modular software components. 
A ”f oreground/backgroand" concept will be implemented with 
SPLICE minicomputers, which will serve as a front-end- 
processor for the existing stock points medium sized 
Burroughs systems. 'Ref. 11: p. 1] 

More than twenty new applications systems under develcp- 
nent and the current OADPS/SP system comprise the "SPLICE 
Umbrella." These systems will require considerable interac- 
tive and telecommunications support at more than fifty 
UADPS/S? activities. SPLICE will provide a respcnsive and 
economical support capability without saturating the current 
Burroughs mainframes, and will simplify the eventual main- 
frame replacement [Ref. 11: p. 1]. SPLICE will present, a 
user oriented environment which will provide many standard 
operating functions such as terminal management, communica- 
tions management, database management, and peripheral 
management. Additionally, there will be many support func- 
tions such as standard software tools (compilers, etc.), 
recovery management, and security. The existing Burroughs 
mainframes will provide large file processing functions and 
report generation. 

As seen in Figure 1.1, the evolution of computer tech- 
nology has resulted in the design and implementation of very 
complex and sophisticated automated environments. The risk 
of operating these new environments is directly proportional 
to their overall complexity. As a point of reference, the 
operational SPLICE Network will fall at the very high end of 
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Figure 1.1 Technology versus Complexity 



t.he technolcgy and complexity stales. The Navy's increased 
op^rdLionax d s p 0 nd 8 ii cr j. <rS on du c 0 inn n 8 G oyst-duis QdiTidnG ondG 
the risk in SPLICE be evaluated and managed at an acceotable 
level, 

D. OBJECTIVES OF RESEARCH 

Research by Naval Postgraduate School faculty and 
students on the SPLICE Project is concerned with systems 
analysis and preliminary design proposals for many of the 
functional areas of SPLICE. Phis thesis defines a Risk 
Management Program to evaluate and manage the risk associ- 
ated with the operation of SPLICE. The methodology proposed 
draws upon current government and industry techniques and 
conforms to existing DON and NA7SU? guidance. 

Ref. 11 tasked NAV3QP 0'4 15 and the Fleet Material 
Support Office (FHSO> 94 with conducting a risk analysis of 
the SPLICE system. It is intended that the Risk Management 
Program proposed in this thesis be used as a tool to quan- 
tify the risk in SPLICE. Together with information about 
and simulation of tie eventual operational SPLICE activi- 
ties, this tool can oe used to identify those initial design 
specifications needed to reduce the risk in SPLICE. 

E. LIMITATIONS AND ASSUMPTIONS 

y. Defuse Data Network 

The original SPLICE specifications required the 
Network Interface Subsystem to provide access to the AUTODIN 
II Network [Ref. 13: p. 57]. On 2 April 1982 Deputy 

Secretary of Defense Carlucci directed the termination of 
the AUTODIN II program and the immediate development of the 
Defense Data Network (DDN) *Ref. 14], It is current DOD 
policy that all data communications users will be integrated 
into the DDN, 
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It is assume! that the 3PLIC3 lietwDrk. will ctsprise 
a "cofn 'Tiuni t y of interest” within the DDN. n brief iesrric- 
tion of the DDN ani a summary of the security feat ires 
provided by the DDN is included as Appendix C. 

2. Level II Data 

It is assumed that the data processed within the 
SPLICE Network is Laval II data, which is defined in Ref. 10 
as unclassified data requiring special protection. Since 
the SPLICE application syscems will be processing financial 
and other management, data which is by definition "Sensitive 
Business it r^quir^s pr o t ion for r 95. sons oihsr 
than being classified or personal data. It is judged that 
the potential impact of modification or destruction of the 
data is severe enough to justify a greater degree of protec- 
tion than reguired for other unclassified information. 

3. Act^itj ADP Security Plan 

The majority of SPLIIE configurations will be 
located at Navy AD? activities, which are subject to the 
Department of the Na/y ADP Security Program [Ref. 10: p. 3]. 
Although the proposals set forth in this thesis follow the 
guidance of Ref. 10, they are concerned only with the risk 
management of the SPLICE conf iguration (s) and w^ll not 
constitute an Activity ADP Security Plan. The Activity ADP 
Security Plan must be much more comprehensive in order to 
implement the overall Activity ADP Security Program. In 
particular. Appendix J of Ref. 10 outlines the mandatory 
minimum requirements for DON \DP activities. Additional 
minimum security requirements for SPLICE are given in Refs. 
11 and 15. 
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Each applications softirars system must provide its 
own unique internal security and data inregriry, adhering ro 
activity software development policy. Examples of such 
applications software inregrity considerations are computa- 
tions of money figures (such as what to do with remaining 
fractions of cents, if any) and maintenance of application- 
unique audit trails (such as tie Transaction Reconstruction 
File in UADFS/SP). A.t a minimum, applications software must 
incorporate security and audit controls listed in Appendix I 
of Ref. 10. Applications processing financial data should 



adhere to NAVCOMPTINST 7003. 35 , 

Sy st ems; St andard criteria for A DP i nterna l c on tr ol of. 
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II. QVER7IE» OF SISK MANAGEMENT 



A. RISK MANAGEMENT TERMINOLOGY 

Befor? proceedinj with a discussion of the functional 
phases of risk management, it is essential that the terms 
risk, threat, vul nera bilit / , and countermeasure be 

explained. 

I • Sisk 

In Webster’s Collegiate Dictionary, risk is defined 
as the possibility of loss or injury; a dangerous element; 
or the degree of probability of a loss. 'Jnf or tunately, the 
term risk is not a universally de-fined term. Risk is 
perceived differently, depending on the circumstance or 
community. 

The insurance industry uses the idea of an '‘insur- 
able risk." A company identifies both the known and 

uncertain elements of operating a business and minimizes 
their potential loss by buying insurance. The insuring 
agent, using empirical and statistical data, sells protec- 
tion to the company in the form of financial compensation 
should its assets be lost. To determine how much risk is 
involved, the agent relies on historical data, prediction 
models, and business experience. Unfortunately, the 
computer industry is relatively new and lirtle analytical 
data is available for assessing the areas and extent of 
potential security risks. 

In business economics, there are two types of risk: 
speculative and pure. When a bisiness invests, and there is 
a degree of uncertainty as to whether that investment will 
result in a gain, the risk is speculative. If the only 
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or no change. 



possible outcome is either loss or no change, the risk is 
classified as pure. 

In t.he context of AD? security, only a pure risk can 
exist. Risk within rhe data processing community is defined 
as the likelihood of a loss and the expected amount of that 
loss with respect to the assets of an activity. 



Thr eat 



H. Stephen ."lorse of the System Development 

Corporation defines a threat as any action, event, or 

circumstance, the occurrence of which is likely to adversely 
affect the assets of an activity. Threats exist in general 
because of the unpredictability of the real world and 

people. The presence of a threat does not equate to harm or 

loss. For that to happen, there must be a successful attack 
by a threat agent using a specific technique, methcdolgy, or 
spontaneous occurrence. 

Threat agents are classified as natural environ- 
mental factors (tornado, flood, firs, etc.), authorized 
users (programmers, operators, etc.), or hostile agents 
(anyone not an authorized useri . A threat agent causes a 
threat to be realized by attacking the assets. The attack 
can impact these assets in at most four areas: modification, 
destruction, disclosure, or denial of service. Whether the 
attack renders harm or loss to the activity is dependent 
upon the threat agent successfully penetrating the existing 
countermeasures and exploiting weaknesses (vulnerabilities) 
in the data processing environment. 

The threats facing an activity can be a function of 
its geographic location, personnel workforce, processing 
mode, physical facilities, or computer system configuration. 
Since these elements are constantly changing, threats are 
considered dynamic and should be continually monitored. 
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[Ref. 16 : p. 174 ] 



Figure 2. 1 Some Typical Thraats and Their Usual Defease. 

Perhaps the easiest way to understand threat is by 
an example. Although the existence of threats is beyond our 
control, a threat will not neoessarily materialize or oause 
harm. There is always the threat of a fire, but that does 
not mean there will be a fire. The occurence of a fire and 
the extent of damage a fire woild cause depends in part on 
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the wealcnssses in the facilizy. Ths weaknass, in this case, 
is the lack of firs pravantion measures. Figure 2.1 snows 
some typical threats and their usual defense. 

3. 7ul nerabi-lity 



OFNAVINST 5239. 1A defines a vulnerability of a 
computer system as a weakness ii its physical layout, organ- 
ization, procedures, hardware, or software that may be 
exploited to inflict harm. As with a threat, the presence 
of vulnerability does not in itself cause harm; a vulner- 
ability is merely tie condition or set of circumstances of 
which the threat agent can take advantage to inflict danage. 



fRef. 10: p. A-17] 

The vulnerabilities of a computer system increase 
directly with its complexity; remotely accessed resource- 
sharing computer systems that allow remote job entry are 
significantly more likely to have weaknesses than a dedi- 
cated, batch-processing, stand-alone system with no remotely 
located terminals. Figure 2.2 illustrates some potential 
vulnerabilities of a computer system. 

One purpose of evaluatiig a data processing environ- 
ment is to identify all vulnerabilities existing in the 
facility, system, or operation. By conducting a thorough 
analysis of identified weaknesses and weighing each of the 
probabilities of a successful attack by a threat agent, the 
vulnerabilities of the data processing environment can be 
measured. Vulnerabilities, unlike threats, are generally 
under the control or influence of the data processing 
management, and can be modified to reduce the severity of an 
attack. 
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Figars 2.2 Potsntial Computer System Vu Inerabilitie 
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4. 



Co unternieasur a 

Th® words coun tsrasasuras , safeguards, protscfi^a or 
backup measures, and control mschanisms are often viewed as 
being synonymous. A countermeasure is any protective 

action, device, procedure, technique, or mechanism that when 
implemented reduces the activity's vulnerability to 
successful attacks. These corrective features are designed 
and developed to protect the assets of an activity. The 
purpose of a countermeasure is to either reduce the prob- 
ability of a successful attack or minimize the impact of an 
a't^dck. C cun 'diT m 3 d H 'Ji 'T'^ s -h.3zr3ncir3 nicdl cn 

rial mechanisms for controlling the risk to which an 
activity is exposed. Some examples are contingency plans, 
backup copies of software, access control procedures, and 
audit trails. 

As shown by Figure 2.3, risk management is concerned 
with the interaction among the terms just defined. Risk is 
the extent and probaoility of loss due to the manifestations 
of threats (attacks) at points of vulnerability in liaht of 
installed countermeasures. 

B. RISK MANAGEMENT: A FONCTIONAL APPROACH 

Risk management with respect to computers is a new 
discipline that provides quantifiable techniques for 
assessing the risk of operating a computer system in light 
of existing protection measures, and determining the 
requirement for additional countermeasures to protect that 
system. Leading authorities in the data processing industry 
are using various techniques for analyzing risks. However, 
most agree on a formal, four-phased approach to risk manage- 
ment; risk analysis, management decision, risk control, and 
operational continuity. 
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ATTACK SUCCEEDS IF 
COUNTERMEASURES ARE 
INADEQUATE AND 
VULNERABILITY IS 
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Figure 2.3 Factors of Risk Management. 
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For a risk managsment program to effectively er.forcs “he 
kvP security policies ana conaral the AD? securiry posrare 
of an activity, a tonal comii itment is needed froja nop 
management. High level attentica will improve nhe coopera- 
tion across interdepartmental lines and will foster an 
increased security awareness. Top management commits itself 
to a risk management program by making resource allocations 
in terms of both skilled manpower and budgetary allotments 
and by integrating security objectives into the existing 
managerial responsibilities at all levels. 

Top management is also responsible for promulgating 
policy on the fregue.icy and cenditicr.s itr initiating the 
risk analysis phase. According to Ref. 10, a risk analysis 



will be conducted at lea: 



everv 



:nve years, 



or wr.enever in 



the iudgement of top management a system configuration or 
facility -change has been effected that warrants a requanti- 
fication of the risk. 



I* Si.§JS A na lysis 

The guantif ica tion of risk is not new. As early as 
the seventeeth and eighteenth centuries, noted men such as 
Pascal, Bernoulli, and Bayes applied risk analysis 
techniques to ''games of chance." Risk analysis has recently 
been applied to the data processing environment, expanding 
the "game of chance" from computing the odds for a win to 
quantifying the probability of loss or harm for a computer 
system. 

The purpose of conducting a risk analysis of a data 
processing environment is to quantify the damage and opera- 
tional impact resulting from the successful attack by a 
threat agent and the likelihood of such an attack occurring 
[Ref. 17: p. 8]. The analysis produces an annual loss 

expectancy (ALE) value, which is a quantitative es-'^imate of 
the potential average yearly financial loss resulting from 
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any accidental oc iatennicnal unauthorized modification, 
des~ruc“icn , disclosure, or denial of service. This ALE 
value is a baseline for assessing rhe ADP security posrure 
of an acriviry. 

As shown by Figure 1.1, the risk an activity faces 
is directly proportional to the complexity of its data 
processing environment. Because of this, top management 
bases the scope and depth of the risk analysis on the 
complexity of the particular environment being evaluated. 
Some factors that are pertinent to the decision are the 
value of the physical facility, the value of the data (both 
internally to the activity and externally to ethers), the 
configuration of the ADP system, and the criticality of the 
data processing service to the activity’s and users’ 
missions. 

The risk analysis technique attempts to predict 
future risk exposure of an activity based on a thorough 
evaluation of its assets, threats, vulnerabilities, and 
existing coiontermeasur es. This evaluation relies heavily on 
the professional experience and technical knowledge of the 
risk analysis team. For this reason, it is vital that the 
team be drawn from both the data processing department and 
the users* departments in order to take advantage of their 
diverse backgrounds and technical expertise. The team 
members should be highly skilled professionals, whose selec- 
tion will substantially influence the quality of the final 
risk analysis product. Additionally, the risk analysis team 
must be supported at all levels if the analysis is to accu- 
rately reflect the security posture of the activity. 

2. Man agement Dec isio n 

In this phase top management decides, based on the 
risk analysis, the activity’s mission, and the users’ degree 
of dependence on automation, if the existing countermeasures 



32 



provide sufficient protection. Before making this decision, 
top management reviei^s the risk analysis to determine if 
appropriate assumptions were made and operational 
constraints were considered. The risk analysis quantified 
the "current level" of risk associated with operating the 
existing computer system and documented the activity's ADP 
security posture. The risk analysis should be presented to 
top management in such a manner that decisions can be made 
in relation to the documented threats, vulnerabilities, and 
countermea sures . 

At this junction, the Risk Management Program can 
follow one of two directions, contingent on the decision of 
top management. If top management judges the current level 
of risk as acceptable, then the Operational Continuity Phase 
is entered. By progressing directly to that phase, top 
management is explicitly acknowledging that existing control 
practices and procedures are sufficient and the current 
security level is to be maintained. On the other hand, if 
top management decides that the current level of risk is 
unacceptable, than the Risk Control Phase is initiated. 
This means that top management is not willing to tolerate 
the risk. Before the Risk Control Phase is begun, top 
management should assign a risk control team and provide 
guidance abouts those deficiencies of greatest concern. The 
risk control team should be composed of a greater proportion 
of data processing technicians chan the risk analysis team. 

3* Hisk Control 

The function of this phase is to propose to top 
management an optimal set of countermeasures that have 
proven cost-effective and technically feasible. The coun- 
termeasures needed to bring the risk of operating to an 
acceptable level are selected from a combination of risk 
avoidance and reduction techniques. 
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within the iit.a processing environinen':, e risk is 
avoided by determining that a, particular &DP specification 
should be abandoned, redesigned, or deferred because the 
potential harm is too great to be controlled with existing 
technology. Councerm easures no reduce risk fall into three 
basic categories: 

• Protective measures which reduce the damaging effecrs of 
external events. 

• Control measures which reduce the likelihood of unde- 
tected errors or fraudulent modifications and 
u na at. iic r rze d drsc— osure. 

• Back-up (contingency) measures which provide alternative 
means for carrying on the mission of an activity subse- 
quent tc an event which disrupts normal operations. 

[Refi 18: p. 22U ] 

After top management selects and approves those 
measures that have the greatest potential of minimizing the 
overall losses, the risk control team prioritizes them for 
implementation. This phase is complete wnsn top management 
accepts the set of proposed additional countermeasures and 
approves their implementation plan. 

Ope rational Continuity 

The Operational Continuity Phase is initiated eicher 
after completion of the Risk Zontrol Phase or immediately 
following the Management Decision Phase. If the Risk 
Control Phase was executed, resources are dedicated in this 
phase to carrying out the action plan developed for imple- 
menting the approved additional countermeasures. 

During this phase, the DAA makes the technical and 
managerial policy decision regarding the accreditation of 
the activity. That decision is made immediately if no Risk 
Control Phase was executed, or after the implementation of 
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additior^al countemeas arss. ?. agardlass Df whsther or not 
additional countecmsa'sura s are being implemented, the 
process of risk management continues. This ongoing of tort 
is considered essential to preserving the ADP security 
posture of the activity and includes continual review, 
audit, and evaluation of the data processing environment. 
This phase is terminated when it is deemed necessary to 
reinitiate the Risk Analysis Phase because either a five 



year time interval has passed or the policy 
ment so dictates. 



>f top manage- 
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III. 3ISK MANA3EHENT PROGRAM 



The proposed Risk Management Program famishes a frame- 
work which is tailored to the unique aspects oi the data 
processing environment. The fnandation of this program is 
taken from Refs. 2 and 10 ani the recent experiences of 
industry. Quantitative techniques are used in the Risk 
Analysis and Risk Control Phases. These techniques do not 
utilize exact values; instead, values are scaled by orders 
oi magnitude. The use of relative magnitude is to accomo- 
date the lack of empirical data, incomplete knowledge on the 
future likelihood of attacks, and inconclusive proof of the 
effectiveness of countermeasures. 

As a first step in establisiing a formal Risk Management 
Program, it is recommended that activity top management 
implement a managerial structure which includes an ADP 
Security Staff as described in Ref. 10. The activity is 
directed to the Commander, !1aval Data Automation Command 
(COHNAVDAC) for technical assistance in conducting a risk 
analysis. Within the DDH, CDHNAVDAC is responsible for 
providing assistance as requested and with ensuring that 
risk management expertise is shared across activity 
boundaries . 

This chapter is broken into the phases of a Risk 
Management Program and is intended to meat two objectives. 
The first is to describe in a cohesive manner the philosophy 
of each phase. The second is to give, where necessary, 
specific implementation considerations independent of the 
philosophy. 
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A. SISK ANALYSIS 

According to Ref. 10, there are three distinct steps in 
a risk analysis. These steps, as shown in Figure 3.1, aust 
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Figure 3.1 The Major Steps of Risk Analysis. 

be completed in sequential order. The purpose of the Risk 
Analysis Phase, is to quantify in accordance with the policy 
guidelines from top aanagement the risks of a specific data 
processing environment in relation to its threats, vulner- 
abilities, and existing countermeasures. The following 
conceptual model and implementation considerations elaborate 
on how this quantification is performed. 
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Model 



Th.0 iTLsk 2.n3.Lysi.s iriDd3L is 3.n sbs't^rs.cticn 
risk analysis procsss pr=sent.ad in Appendix E of Ref. 10. 
It takes into account the work of Robert H. Courcney 
[Ref. 3], NBS [Ref. 17], and Jerry Fitzgerald [Ref. 19]. 
The model allows one to systematically quantify asset losses 
and attack frequencies on an annualized basis and to calcu- 
late from these the total annual loss expectancy (ALE) of an 
activity . 

a. Asset Loss Determination 

This step identifies all of the assets within an 
activity and quantifies the activity’s loss should they be 
harmed. The degree to ifhich assets should be separately 
identified is addressed in the implementation considera- 
tions. In addition to naming an asset, a textual 
description is written to document how that named asset 
could be impacted by threats i.i general. Next, for each 
named asset, four loss values are determined, one for each 
threat impact area. The four threat impact areas are modi- 
fication, destruction, disclosure, and denial of service. 
Each loss value is an estimaoion in dollars of what an 
activity will lose if one attack is completely successful in 
causing harm in that impact area to the asset. Put another 
way, given that there is a one hundred percent probability 
of one successful attack, how much is an activity willing to 
pay to prevent that attack? This step is completed by 
transforming each loss determination into a loss rating 
[Ref. 17: p. 10]. The model component representing this 

step is summarized in Table II. 
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TABLE II 

Asset Loss Detacaination Model 



1 



The loss detarmin at Id n faaotiori/ L(i,A), is an 
empirical estimation of loss, in dollars, of asset 
A in impact araa i, roaniad to the naarest expo- 
nential value of ten. 

The function is expressed as; 

L(i,A) = function [D(A), N(A) ], rounded 

Where; 



= the threat impact araa (modification, des- 
truction, disclosura, cr denial of service) 



A 


= the 


unique name of 


an asset 




D(A) 


= the 
fee 


description of 
ted by threats 


iow asset A 


could be af- 


N (A) 


= rhe 
the 


number of iden 
same threats 


tical assets 


A subject to 



The loss rating function is a logarithmic mapping 
from L(i,A) onto an ordinil inteaer scale ranainc 
from 0 to 8. Tie zero ratine indicates asset A is 
not affected in a particular ' impact area i. 

The function is axprassad as; 

LOSS (i ,A) = log [ L (i , A) 1 

1 3 
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b. Threat and Vulnerability Evaluation 

This step identifies each threat which could 
possibly affect the assets of an activity, provides perti- 
nent textual descriptions, and expresses the probability of 
an attack with an annualized frequency rating. The first 
description defines the threat and enumerates specific 
threat agents. The second description discusses the vulner- 
abilities which are susceptible to attacks by threat agents. 
The last description describes existing countermeasures 
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installsd tc countec thos“ attacks. Exa^nplas of threats 
cotntnom to the current miaicoapiter er.yiror.nent are iiaati- 
fied in the implementation consi 2 = rations. 

Since the realization of a threat can have an 
impact assets in four areas, four frequency occurrences must 
be estimated. The frequency occurrence represents, on an 
annualized basis, how often a threat agent can be expected 
to penetrate the defenses of an activity and successfully 
attack assets. This step ooncludes by transforming the 
frequency occurrence for each impact area into a frequency 
of successful attack rating [Ref. 17; p. 10]. The model 
component for this step is summarized in Table III. 

c. Computation of the Total Annual Loss Expectancy 

(ALE) 

The final step of the risk analysis calculates 
the activity's Total ALE by a series of computations. The 
Total ALE quantifies the average yearly risk exposure in 
dollars resulting from modification, destruction, disclo- 
sure, or denial of service. The activity's risk exposure 
reveals the degree to which the existing vulnerabilities 
permit threats to be realized against the assets of the data 
processing environment. The first computation uses a matrix 
of all assets and threats for each impact area. An ale 
(uncapitalized) is computed for each combination of loss 
rating (of a single asset) and frequency of successful 
attack rating (of a single threat) paired by rhe same impact 
area [Ref. 17: p, 10]. This ale is the risk exposure for 

that specific asset and threat inrersection. The second 
computation computes the ALE for impact area i as the sum of 
all ala's in impact area i. The last computation totals the 
four impact area ALEs . The model component for this last 
step is presented in Table IV. 



40 












<=u;;iii|ioij;i™ 

.: ■ ®ioij|ioij;ii= . 

iii;ii;ii;ii;ii;ii;ii;iiVii;ii™^^^^^ ■ , 










■mr 




f 



TABLE III 

Threat and ffilnerability Evaluatioa Model 



The freouency occurrence function, F(i,T), is 
a stochastic estimate of the frequency per year 
of successful attack by threat T in impact area i. 

The function is expressed as: 

F(i,T) = function [D(T), 7(T), C(T)] 

W here : 

i = the threat impact area (modification, des- 
truction, disclosure, or denial of service) 

T = the uniquely named threat 

D (T) = the definition of threat T and listing of 
of specific threat agents 

V (T) = the discussion of tiie vulnerabilities which 
allow threat T to materialize 

C (T) = the descriotion of :he existing countermea- 
sures to counter threat T 



The frequency of successful attack raring is a 
mathematical maoping from F(i,T) onto an ordinal 
integer scale iranaing from 0 to 3. The zero 
rating indicates that threat T does not affect anv 
of the activity’s assets in a particular impact 
area i. After the ratian is computed, it is 
rounded to the nearest integer. 

The function is expressed as: 

ATTACK (i,T) = log^^[ 3000 x F(i,T)], rounded 



2- Imp lementatign Considerations 

Top management begins this phase by selecting the 
risk analysis team and providing them policy guidance on the 
scope and depth of the risk analysis. The members are 
assigned in writing and their accompanying duties and 
responsibilities are documental. Team selection is based 
not only on individual diversity of specialized technical 
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TABLE IV 

Activity Total ALE Computation 






The individual “ale" Eunotion is a raatasmarical 
mapping from LOSS (i,A) and ATTACK (i,T) cr.ro the 
the annual loss axpectanoy, in dollars, associated 
with each combination of asset A ana threat T, 
having the same impact area i. 

The function is expressed as; 

ale(i,A,T) = 

1/3 * 10 exp ;LOS3(i,A) + ATTACK (i,T) - 3] 



The ALE function bv imoact area i is a summation i 
of rhe "ale"s co mpured' abo ve and is expressed as: 



ALS(i) 



z 




al e ( i 



A,T) 



I 



The activi-v Total ALE function is a total of the 
four impact'area ALSs and is expressed as; 



Activity Total ALE 



ALE (i) 



V i 



L 



J 



talents, but also on familarity with the activity’s mission 
and knowledge of the data processing services provided. 

The scope and depth of the risk analysis depends on 
the complexity of the data processing environment. The 
SPLICE Network, as previously described in Section I.C., 
will be a decentralized, interactive, telecommunications 
environment. Risk increases in direct: proportion to the 
complexity of the data processing environment. The SPLICE 
falls on the high end of the complexity scale as seen if 
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Figure 1.1. Tr is because this ootenrially large risk 
exposure that the policy guidance concerning rhe risk 
analysis should at rhe least address the following. 

The risk analysis conducted during the developcae nral 
phase of SPLICE will be different from the analysis 
conducted after rhe system is operational. The risk in the 
developmental phase is quantified either by simulating the 
operational environment or by comparing the eventual opera- 
tion to one already in existence. The analysis of the 
developmental phase deals with educated estimates and design 
“til? 6 ccn si d ^ ions ^ whils ihs 5. n-9.lv sis o? *ths onsrs-iionsl 

system deals with concrete data and mission-essential 
reauirement s. Since a risk anilysis is required early in a 
system's life cycle, hardware and software countermeasures 
can.be included in the final specifications and implemented 
at a reasonable cost-. If the risk is not evaluated until 
the operational stage, many technically feasible countermea- 
sures are no longer practicable and less effective control 
measures are used to manage the risk. 

As stated earler, a risk analysis is reinitiated 
either after five years or whenever the data processing 
environment has been affected by a significant change. Due 
to this recurring cycle, policy guidance is needed on the 
applicability of a previous rise analysis. Host of industry 
agrees that if five years has passed, then the risk should 
be thoroughly reexaalaed and documented. Dn the other hand, 
if only one area has realized a major change and less than 
five years has passed, then only that portion of the envi- 
ronment should be reevaluated. During the reevaluation, the 
risk analysis team is cautioned not to overlook those areas 
indirectly impacted by the change. 

The final area requiring policy guidance concerns 
the level of detail required to document the estimated loss 
expectancies and frequency occurrences. The degree of 
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granulirity ioiposei by top maaageaient dirsocly corr<rla' = 3 -c 
the time and resources required to conduct an ac-ivity risk 
analysis. The level ot derail should be sufficient enough 
for the risk analysis to be judged credible and defensible. 

Having discissed the policy areas requiring the 
attention of top management, it is now time to focus on the 
practical considerations of actually conducting a risk 
analysis. The guidelines provided in the next two sections 
are general rules of thun^ synopsized from Refs. 10, 33, 20, 
and 21. Ref. 10, Appendix E contains the forms required by 
the DON for documenting an activity's risk analysis. 



a. Asset Identification and Loss Expectancy 



Assets which functinn as a single unit or appli- 
cation are identified as a whole asset, since all of its 
components must be working for the asset to be serviceable. 
Likewise, if any component is damaged, the entire asset 
should be equally as likely to suffer the same damage as the 
component. Asset identification proceeds by reviewing the 
bread resource categories listed in Table V and by adding 
additional assets that are unique to the activity. The 
current DON guidance states: 



For each asset defined, all components of this asset 
should be in the same ohyiscal area. pronected in r he 
same manner, and subject to damage by the same threats. 
For example, consider six identical computers as six 
separate assets because damage to one of ~hem would not 
imply damage to all of them. On the other hand, do not 
treac a single computer as a collection of subparts 
because if one of these comoonents were to fail, the 
entire computer would be damaged to a similar level. 
[Ref. 10; p. E-2] 



The level of disaggregation and the method for 
derermining the loss associated with each asset are two 
areas which must be standardized to minimize individual 
interpretations and double counting of losses. Some general 
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TABLE 7 

Asset Examples Identifiai by Resource Category 



The Sever. Zaregories of Assets 



Cate gories 

Information 



Representative Sampling 

System (audit trails, bootstrap files, 
oerformance statistics), application 
'(master files, transaction data, output 
files) , and backup copies 



Hardware 



Software 



Commun ica tion 



Personnel 

Administ r ati ve 
Phys ical 



Central processing system, storage media 
(disk packs, tapes, cards), special in- 
terface eauiPTient (front- and- processor s, 
database machines), and E/0 devices 
(printer, terminals, disk drives) 

System (operating svstem, compilers, 
audit routines), application programs, 
and backup copies 

Telephone circuits, communication proc- 
essors, modems, and multiplexors 

Computer (ooerators, programmers), 
building (janitors, guards), support 
(auditors, secretarial, management, 
librarian), maintenance, and users 

Documentation, operational procedures^ 
user guides, I/O procedures and recocas 

Environmental Systems, buildings, office 
equipment, supplies and auxiliary power 
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guidelines cn the appropriate level of disaggregation that 
can serve as standards are as follows. 

• All information required to perform a single function 
should be grouped accordingly at that functional level. 
This is because only partial information is net suffi- 



cient for 


p erformin g 


the appL 


ication. For 


example. 


the 


master and 


transacti 


,on files 


of a payroll 


s yst em 


must 


both be 


available 


to iss 


ue paychecks. 


This 


same 


reasonin g 


applies to 


the oth 


er soft asset 


cat egori 


es of 



software and adaini stra ri ve loramants and procedures. .’vn 
operating systea aas many conpsnents such as a job sched- 
uler, main memory manager, I/O supervisor, and ethers, 
which must all be operable to perform the task of 
managing the overall sysrem. To consider each component 
as a separate asset would be incorrect because they all 
act as a single unit. 

• The unique identification of fixed assets is somewhat 

easier as their physical boundaries are visually recogni- 
zable. Fixed assets include the categories of hardware, 
communication, and physical assets of an activity, and 
are usually controlled by serial numbers and cusredy 
cards. As with soft assets, fixed assets are grouped 

according to whether they act as a single unit. For 

example, the operator consols of a computer system must 

'be functioning, otherwise the computer system is inoper- 
able. On the other hand, if one tape drive in an 

inventory of six starts to malfunction, only that taps 
drive is affected, not ail of them. 

• For the remaiaiig asset category cf personnel, no 

universal grouping method exists. Each activity must 

decide based upon their particular situation which 
grouping alternative is best. Some potential alterna- 
tives are by skills, experience, salary, department 
assigned, or job classification. 

Deterrainiig the loss of an asset requires 
careful attention to how essential it is in supporting the 
mission and how much an activity will lose if it is damaged. 
The user expresses how essential an asset is by assigning it 
a crit icality value that reflects the importance given’ to 
the utilization of that asset. As expected, it is not an 
easy decision, and once made should be reviewed and approved 
by all levels of management relying on that asset. 
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For fixed assets, tne loss value for modifica- 
tion and destruction damage is determined by the repair 
cost, original cost, ar replacenenr cost. Additionally for 
destruction, the loss value includes the cost of doing 
without that asset. For disclosure damage, the user quanti- 
fies the loss by determining the worth of the asset to 
someone else, such as a hostile agent (any unauthorized 
user). The remaining area of denial of service is much 
harder to quantify. One must envision a ty pi cal timeframe 
during which the asset would be unavailable to satisfy the 
user’s demand for processing and estimate the maximum time 
period that is tolerable for the user to be without the 
service of that asset. Then, using these two timeframes, 
one determines the estimated cost of getting that service 
from a commerical tiaesharing company, realizing that the 
user with the shortest tolerable time period has the most 
critical need for service. 

The soft assets of information, software, and 
administrative documeats and procedures are subject to the 
same four areas of damage (modification, destruction, 
disclosure, and denial of service) as fixed assets. 
However, in determining their loss values for modification 
and destruction, a different approach is taken. Some soft 
assets of an activity are generated by an internal project 
team or created uniquely for a particular function of the 
activity. This means that if such an asset is destroyed, 
the loss value is estimated by the cost of recreating the 
asset and of doing without it. For modification damage, the 
loss value is determined by either revalidating all the 
files or recertifying the administrative documents and 
procedures. To quantify the damage resulting from disclo- 
sure or denial of service, the guidelines given for fixed 
assets are appropriate. 
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The issae of qaa.i ti fying the loss value of 
assets for which there are replacement spares or duplicate 
copies needs clarification. If a terminal is destroyed for 
which there is a spare, then the loss due to destruction is 
only the terminal's replacement and installation cost and 
does not include the cost of not having the service avail- 
able. If no spare is available, then the loss from 

destruction includes all three costs. Likewise, some soft 
assets, such as centrally designed software or off-the-shelf 
documentation, are easily replaced from another activity or 
commerical vendor. For example, if an application system 
for which there is a duplicate copy is modified or 

destroyed, then the loss value only includes the overhead 

and computer running time needed to install the backup. The 
point is that the loss value of assets for which there are 
replacements must only reflect the cost to install the 
backup and replace it. That cost might include the addi- 
tional costs tc bring the backup version into operational 
use. 

When quantifying the loss value of personnel, 
one takes into consideration the availability of qualified 
personnel, whether unique training or knowledge is required, 
and the activity's aoility to absorb the loss based on the 
current number of skilled personnel. 

In summary, the importance of this step cannot 
be overemphasized since the data collected dramatically 
affects the analysis. The implementation considerations 
presented should be viewed as a baseline for the risk 
analysis team. Many additional constraints and guidelines 
are unique to each particular activity and must be identi- 
fied and documented. 
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A 



b. Threat 



mi yulrerabi Lity Svaluacicn 



Ip. the previous section, guidance was givsn on 
quantifying the loss expectancy of assets. This section 
addresses the opposite side of that task; how an activity 
identifies the potential problems and hazards of running a 
data processing environment. 

The risk analysis team begins by marking those 
assets critical to the activity's mission and adding those 
additional ones which might be very attractive to someone 
external to the activity. Someone may want the asset 
because oi whar could oe gained by corrupting its internal 
contents, learning its function or meaning, or denying the 
activity possession. 

With the assets just marked in mind, the team 
th'en considers all the potental threats that, if realized, 
could inflict damage. One starts by considering the 
possible adversaries that would take advantage cf any oppor- 
tunity to attack the activity. Basically, this means 
listing the most likely threat agents (natural environmental 
factors, authorized asers, and hostile agents) and specu- 
lating on how they could hurt the activity. 

To complete this review, it is prudent to ask 
where might each attack occur, such as at the computer main- 
frame, remote terminal, programming office, or tape library, 
additionally, one should ask when might it happen; during 
normal working hours, on holidays, just after a shift 
change, or during an emergency such as a system crash, power 
failure, or fire. 3y doing this additional review, poten- 
tial threat scenarios can be documented and evaluated. 

Having listed every plausible threat scenario, 
the team determines how the potential attacks could harm the 
activity. This refers back to the four treat impact areas 
of modification, destructon, disclosure, and denial of 
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service. In addicinn to dsternining the impact area, ar. 
evaluation is made concerning .low often a threat mighr be 
perpexrared . This evaluarion accounts for the probability 
of each scenario occurring, giiren the existing iDP security 
posture of the activity. 

In summary, one identifies threats by consid- 
ering those threats that: 

• have been known to occur at the activity in the past: 
machine failure, theft, system crashes, information loss 
and vandalism; 

• might occur with some reasonable probabilitv in the 
geographic area: fire, earthquake, and flood; and 

• could result from accidental or intential errors of 
humans. [Bef. 22: p. 32] 

As a starting point, some threats which are 
common to the currant data processing environment have been 
listed in Table VI. Additionally, the impact area(s) asso- 
ciated with the realization of each threat is (are) marked 
accordingly. The examples are a representative sampling 
which the risk analysis team can use as a checklist of 
potential threat areas. For a more exhaustive threat evalu- 
ation the reader is encouraged to read Martin (1S73), N3S 
FIPS 31 (1974) , Ref. 20, and Ref 22. 
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B. MANAGEMENT DECISIDN 



In this phase of the Risk Management Program, activity 
top management judges whether the level of risk attributed 
to the data processing environment is acceptable. 

Before making that judgement, top management appraises 
the risk analysis. This appraisal includes conducting a 
sensitivity analysis on the data used to substantiate the 
Total ALE and evaluating the technical merits of the overall 
analysis effort. The sensitivity analysis determines what 
effects changes in the estimate! data can have on the Total 
ALE. The technical merits can be evaluated by asking the 
following types of questions. 

• Did the users participate in estimating the loss expec- 
tancy of assets? 

• Was the risk analysis team adequately skilled and experi- 
enced to make the appropriate assumptions? 

• Are the results realistic and defensible? 

• Can the results be replicated by another team? 

• Were the calculations performed correctly? 

• Were the existing countermeasures sufficiently considered 
in the analysis? 

• Did the risk analysis team adequately consider the activ- 
ity’s mission and users' dependence on automated support? 

If the results of the risk analysis are not accep*:a ble, 
top management identifies the deficiencies in the analysis 
and reinitiates the Risk Analysis Phase. If -he results are 
acceptable, top management approves the risk analysis. 

After the risk analysis is approved, top management 
decermines whether all mandatory countermeasures have been 
implemented. This is dons by comparing the list of manda- 
tory countermeasures with the existing ones documented 
during step 2 of the risk analysis. 
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Top management next evaluates the Total ALE. The deci- 
sion of whether the Total ALE is acceptable depends 
exclusively on the amount of risk that top management is 
willing to assume, given the activity's mission and users' 
dependence on automated support. Many judge the level of 
risk as acceptable when the loss per year is so small that 
the activity's overall mission is not significantly degraded 
if threats are realized. Since each activity has a unique 
combination of assets, vulnerabilities, personnel, and 
security policies that establishes its data processing envi- 
ronment, no universally accepted ALE is appropriate for all 
activities. [Ref. 23: p. 2] 

The pertinent decisions relative to this phase are 
modeled by the decision table in Table Vir. The table is 
divided intc two blocks (conditions and actions). The deci- 
sion table is read by IF condition 1 AND condition 2 AND 
condition 3 are true, THEN take the action marked. When 

evaluating each condition listed, note than the column 
entries indicate the conditional states of satisfied (T) , 
not satisfied (F), or has no bearing (-) . The action block 
lists each decision relevant to the various conditional 
states. The action column entry "X" indicates the action no 
be taken while a blank implies no action required. 

C. RISK CONTROL 

1. Model 

The Risk Control Phase is concerned with selecting 
additional countermeasures to improve the overall ADP 

security posture of the activity. Countermeasures are 

selected which reduce the fregnency of particular threats, 
minimize the loss expectancy associated with particular 
assets, or provide an alternative means of automated 

support. Countermeasures are selected by an iterative 
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TABLE 7II 

Management Dacision Model 



1 



c 

0 
n 
d 

1 
t 
i 
o 
n 
s 


Risk Analysis Credible 
and Defensible 

Mandatory Countermea- 
sures Implemented 

Total ALE Acceptable 


T 

T 

T 


T 

T 

F 


T 

F 


F 




Reinitiate Risk 










A 


Analysis Phase 








X 


c 












u 


Initiate Risk Control 










i 


Phase 




X 


X 




0 












^ n 


Initiate Dperational 










s 


Contiaui-y Phase 


X 









process, in which steps 2 and 3 of the Risk Analysis Model 
are repeated until the projected Total ALE is reduced to an 
acceptable level. This process is executed iteratively in 
order to ensure that the set o£ selected countermeasures is 
the optimal set. 

There are several constraints affecting the process 
of countermeasure selection. The most significant 
constraint is the required selection of countermeasures 
which are designated mandatory by higher authority and must 
be implemented regardless of any other criteria. Higher 
authority is defined as the Designated Approving Authority 
and the organizational chain of command in the DON. 
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The second constraint is that each countermeasure 
should provide a positive return on investment. That is, 
the reduction in Total iLE (an annualized figure) as a 
result of the implenentation of a countermeasure must be 
greater than the annualized cost of the countermeasure. The 
ammortized cost of the countermeasure is computed as the- 
annual operating cost plus the annual portion of the one- 
time costs associated with that countermeasure. The annual 
portion of the one-time costs is the sum of the development, 
implementation, and/or installation costs, divided by the 
number of years in the anticipated life of the 
countermens ure. 

The four step model of the risk conrrol phase is 
presented in Table VIII, and described in more detail in 
Appendix E of Ref. ID. Step one is the examination of those 
countermeasures mandated by higher authority. Those coun- 
termeasures are placed at the top of the priority list for 
implementation. If the projected Total ALE with the manda- 
tory countermeasures, is less than or equal to the maximum 
acceptable Total ALE, the Risk Control Phase is completed. 

If the projected Total ALE after implementation of 
mandatory countermeasures is still not acceptable, addi- 
tional countermeasures must be selected for implementation. 
The selection begins by finding the countermeasure which has 
the greatest potential of lowering the projected Total ALE. 
The process of selecting the aext best countermeasure is 
repeated until the projected Total ALE is reduced to an 
acceptable level. The process is iterative because the 
amount of reduction associated with each countermeasure is 
dependent on the other countermeasures previously evaluated. 
This anomaly is similar to the "law of diminishing returns" 
when two countermeasures affect the same threat frequencies 
cr loss expectancies. 
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TABLE 7III 
Risk Control Model 

Objective: 

Choose Cl throagh Cj so that 
TALE(E + M + Cl +...+ Cj) < HATALE 

By : 

1. Survey all mandatory countermeasures. 

If TALE(E + M) < MAIALE, go to step 5. 

2. Choose countermeasure Cl such that: 

TALE (E + M + Cl) is minimized, and 

TALE (E + M) - TALE( E + H + Cl) > Cosr(CI). 

If TALE(E M Cl) < MATALE, go to step 5. 

3. Choose another countermeasure, Cj, such that: 

TALE (E + M + Cl Cj) is minimized, and 

TALE (E + M + Cl •*•...«• Ci) - 

TALE (E + H + Cl +...+ Cj) > Cost(Cj). 

If TALE(E + M + Cl +...+ Cj) < MATALE, 
gotostepS. 

4. Repeat step 3 until: 

TALE(E + M + Cl +...f Cj) < HATALE. 

5. Develop Plan of Action for implementation of 
necessary* countermeasures. 

Where : 

TALE (E ♦ M) = Projected Total ALE vith existing 
and mandatory countermeasures (annual) 

HATALE = Maximum acceptable Total ALE 

Cost(Cj) = Ammcrtized cost of countermeasure Cj 

TALE (E H + Cl ♦...+ Cj) = Projected Total ALE 

with existing countermeasures, mandatory i 
countermeasures, and proposed countermea- 
sures 1 through j 

* Necessary means mandatory and additional 
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Finally, the optimal set of cd untermeasuras is 
prioritized and schedalsd for implementation. Top manage- 
ment is responsible for approving that recommended set of 
additional counterneasures and their implementation 
schedule. Those considerations addressing prioritization 
are provided in the following section. 



2* Considerations 

The objective of the Risk Control Phase is to 
provide an approved, prioritized optimal sat of countermea- 
sures which, when implemented, lower the Total ALE o f an 
activity to an acceptable level. The task is not a simple 
one, and requires that management devote adequate resources 
in both expert manpower and time to accomplish it. Several 
considerations must be made during the selection of counter- 
measures for presentation to aaiagement. 

The first consideration, as discussed above, is the 
selection of those countermeasures which are designated 
mandatory by high authority. The SPLICE network and indivi- 
dual SPLICE locacions are required to implement those 
countermeasures listed in Appendix J of DPNAVINST 5239. lA 
[Ref. 10] and NAVSaPINST 5510. 5A [Ref. 15]. Additional 
mandatory countermeasures may be identified in future revi- 
sions of the SPLICE Security and Risk Analysis Plan 
[Ref. 11]. 

The second consideration concerns the cost- 
effectiveness of eaca counterneasure. To be a candidate for 
selection, a countermeasure must have a postive return on 
investment. That is, the benefit realized by implementing 
the countermeasure must be greater than the ammortized cost 
of the countermeasure. 

The final consideration in compiling a set of candi- 
date countermeasures concerns the feasibility of each 
countermeasure. Those countermeasures which the risk 
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control team judges infeasibls due to such things as 
geographic location or technical limitations should be docu- 
mented as "considered, but judged infesible." Thorough 
documentation and management participation is crucial during 
this feasibility review to adequately address activity 
budgetary constraints. For those countermeasures judged 
feasible and practical, top management initiates the appro- 
priate planning and budgeting support needed for their 
implementat ion. 

To ensure that the optimal set of countermeasures is 
proposed, the risk control team analyzes the results of the 
risk analysis from several perspectives. The marrix of 
assets and threars is examined to identify those threats 
with the greatest potential for harm, in terms of their 
threat frequencies. Specific countermeasures should be 
considered which redice the likelihood of those threats 
occurr ing. 

Additionally, the team reviews the matrix to iden- 
tify those assets with high loss expectancies. It is 
important to recall at this point that the loss associated 
with an asset is not limited to the replacement value of 
that asset, but is often compounded with the value of the 
service that the asset provides. Those countermeasures 
which minimize the loss expectancies associated with assets 
should be considered for implementation. 

Finally, a global inspection of the risk analysis 
must be taken. During this inspection, top management 
relies on the technical expertise of the risk control team 
to "read between the lines" of the asset/threat matrix and 
to identify those vulnerabilities that allow a variety of 
threats to materialize. The forms required for the evalua- 
tion of countermeasures are provided in Ref. 10. 
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As explained in the Risk Control Model# proposed 
countermeasures are selected in an iterative process. 
Countermeasures are normally targeted to reduce the vulner- 
abilities of an activity and# when implemented# usually 
affect multiple vulnerabilities simultaneously. Due to this 
overlapping result# the effectiveness of a countermeasure 
must be evaluated with respect to the entire data processing 
environment before determining the total benefit that could 
be realized. Additionally# the implementation of a counter- 
measure could in some situations generate a more serious 
vulnerability than that which the countermeasure was 
intended to correct. In this situation# activity top 
management must decide if the benefit gained outweighs the 
weakness created. For example# a recommended software coun- 
termeasure might reguire multiple# lengthy passwords to 
improve access control. Unfortunately# passwords of this 
nature are often written down and taped to terminals# 
thereby negating the effectiveness of passwords and creating 
a greater vulnerability. 

When the projected Total ALE with the additional 
countermeasures considered is less than the maximum Total 
ALE acceptable# the selection of countermeasures is 
completed. The next task of the risk control team is to 
develop a plan of action for implementing the set of 
selected countermeasures. The development of this plan will 
be guided by the availability and timing of those resources 
required for countermeasure implementation. When the set of 
proposed countermeasures and the implementation plan is 
approved by top management# the Risk Control Phase is 
completed. 

Recent ADP security literature provides documenta- 
tion on a variety of countermeasures. A discussion of many 
of those countermeasures is provided in the next chapter. 
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D. OPERATIONAL CONTINOITI 



1 . Model 

Like the Management Deoision Phase, the Operational 
Continuity Phase is modeled by a decision table. The table 
is applicable at any time during the phase, which can be as 
long as five years. Since the Risk Management Program 
requires continual review of the ADP security posture of the 
activity, the decision table should be consulted on a 
continual basis. 

Some elements of the decision table, which is given 
in Table IX, deserve amplification. When an activity enters 
the Operational Continuity Phase, a request for accredita- 
tion is immediately forwarded to the DAA. If the activity 
has no countermeasures which must implemented, this initial 
request can also be considered a final request. If neces- 
sary countermeasures are to be implemented, then a final 
accreditation request will be sabmitted when their implemen- 
tation is completed. 

According to Ref. 13, an activity must conduct a 
risk analysis and be accredited every five years or whenever 
there is a significant change in the system configuration or 
facility. Therefore, a ''Not satisfied" (F) in either of 
these conditions regaires initiation of the Risk Analysis 
Phase, regardless of any other conditions. Finally, since 
the Operational Continuity Phase can be entered from either 
the Management Decision Phase or the Risk Control Phase, a 
likelihood exists that the implementation of countermeasures 
is happening simultaneously wita the daily operation of the 
activity. The responsibilities and authorizations needed to 
implement the necessary countermeasures is addressed in the 
Implementation Considerations. When the Plan of Action for 
implementing the necessary countermeasures is completed, a 
request for final accr editation is submitted to the DAA. 
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2* iSE.i§ 31 sntation Considerations 

When this phase is entered, activity top management 
has approved the results of the Risk Analysis Phase, and, if 
the Risk Control Phase was executed, has approved a list of 
necessary countermeasures and their implementation plan. 
This review and appeoval documentation is submitted to the 
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DAA in support of initial request for accreditation. 

Opon receipt of the request, the DAA will issue an activity 
accreditation that assigns each ADP system of the activity 
to one of the following three categories: 

• ADP systems for which all cost-effective countermeasures 
have been implemented, 

• ADP systems with an acceptable projected level of risk, 
but with some countermeasures not yet implemented (these 
systems will be granted an interim authority to operate 
pending implementation completion), and 

• ADP systems with a unacceptable level of risk which 
requires that operations cease until corrective measures 
have been implemented. [Ref. 10: pp 3-2, 3-3] 

As previously stated, the Operational Continuity 
Phase includes implementing tie countermeasures approved 
during the Risk Control Phase (if any) and conducting an 
ongoing audit and security inspection of the activity ADP 
security posture. Dne individual must be assigned these 
responsibilities and given appropriate authority and 
resources to execute them. Tiat person is designated the 
Activity ADP Security Officer and is the head of the ADP 
Security Staff. The responsibilities of both the ADP 
Security Officer and the staff are presented in detail in 
Chapter 2 of Ref. 10. 

During the implementation of necessary countermea- 
sures, the Plan of Action may require adjustments. To allow 
for this, there must be a responsive two-way communication 
between the ADP Security Officer and top management about 
real world considerations and constraints. Some reasons for 
modification might be unforeseen budgetary changes or 
required implementation of a new directed mandatory counter- 
measure. Additionally, the plan should be "tweaked" to 
minimize the disruption of daily operations. 
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When all necsssary count srineasures have been imple- 
mented and a request for final accreditation has been 
submitted, the DAA evaluates the effectiveness of the new 
countermeasures by means of a Security Test and Evaluation 
(STSE) [Sef. 10; p. 3-6]. After the ST5E, the DAA responds 
to the accreditation request by assigninq each ADP systems 
to one of the three categories discussed above. 

The Operational Continuity Phase is terminated when 
policy dictates rhat another risk analysis is required. At 
a minimum, the Risk Analysis Phase will be reinitiated when 
in the opinion of top managsne.it there has been a signifi- 
cant change to the configuration (hardware or software) or 
facility, or when there has bee.i a lapse of five years since 
the last approved risk analysis. 
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IV. TECHNICAL AND MANAGERIAL CODNTERMEASDRES 



As stated previously, the current data processing envi- 
ronment is viewed as a collection of assets. To protect 
these assets, various technical and managerial security 
mechanisms are imp! en e nted . Technical countermeasures are 
those internal hardware, software, and communication projec- 
tion mechanisms that are peculiar to the ADP system and are 
best addressed in the overall system design specifications. 
Managerial, also called conventional, countermeasures are 
those administrative, personnel, and physical mechanisms 
that are commonly required for the protection of any envi- 
ronment, automated or not. Managerial countermeasures are 
implemented throughout the system’s life cycle and are often 
used to enhance the effectiveness of technical 
countermea sures . 

The ADP security policies which industry enforces 
through the implementation of technical and managerial coun- 
termeasures are: 

• all users and devices require positive unique identifica- 
tion and verification ( autheaticat ion) . 

• all interactions invciving users, devices, and other 
named system elements will be controlled by an authoriza- 
tion strategy (access control) . 

• all activity within the AD? system should be observed sc 
that users (authorized or not) can be detected and held 
accountable for their actions (surveillance) . 

• all elements of the AOP system will function in a cohe- 
sive, identifiable, predictable, and reliable manner so 
that malfunctions are detected and reported within a 
Icncwn time (integrity). 
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The cou nter measuc 2 s discussed in this chapter are organ- 
ized by the four ADP security policies prsssnted above. The 
countermeasures are lot identified specifically as technical 
or managerial because a combination of both is required to 
enforce an adequate AOP security policy. For example, the 
authentication policy is often achieved by implemenring 
passwords. For passwords to be effective, they require a 
software mechanism to accept and recognize passwords and an 
administrative control to properly distribute and audit 
their usage. 

A. AUTHENTICATION 

Authentication counte rmea suras prohibit the use of 
system resources by unauthorized users or devices by 
verifying the unique identity of the user or device before 
servicing a request. 

I* 2§SI Aut he ntication 

User authentication is essentially a two-step proce- 
dure of identity definition and identity verification. In 
the first step, the user provides his or her user identifi- 
cation number and password during initial log-on to the 
system. In the second step, the system performs a table 
lookup and verifies that the password provided correctly 
maps to the user identification number. Additionally, 
administrative controls ensure that each identification 
number/password combination is assigned to only one user, 
and that the user has not provided his or her unique number 
and password combination to someone else. 

User authentication can be performed to some extent 
at the physical security level by such controls as: guards 

stationed at physical entry points, personnel 

sign-in/sign-out logbooks, and closed-circuit monitors. 
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Th< 3 se physical security counteraeasures are not sufficient 
at the ADP system le/sl, particalarly if the system supports 
remote terminals or network communications. As an example, 
when a user submits a batch job to the data processing 
center in person, his or her identity can be verified. When 
that same batch job is submitted from a remote terminal, the 
user's identity is no longer assured. 

There are three methods for verifying a user's iden- 
tity. These methods, which can be applied singly or in 
combination, are based on: 

• something the person knows (e.g., a password, a combina- 
tion to a lock, or a fact about the user's personal 
background) ; 

• something the person has (e.g., a badge, a key to a lock, 
or a card with machine readable information) ; or 

• something the person is (e.g., his or her signature, 

speech, hand geometry, or fingerprints). [Ref. 24: pp. 

8 - 10 ] 

Several commercially developed devices for recog- 
nizing personal attributes such as fingerprints or hand 
geometry are available. However, the cost of implementing 
such countermeasures make them impractical for most decen- 
tralized data processing environmenrs like the SPLICE 
Network. The practicality of their implementation depends 
on the cost of the countermeasure in relation to the amount 
of protection needed to lessen the activity's potential 
losses . 

The most widely accepted countermeasure for 

enforcing an authentication policy is the assignment of a 
unique user identification number and password. The user 
number is entered via a badge or card, or entered from a 
keyboard, whereas the password is generally entered only 
from a keyboard. In addition to its use in authentication. 
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the user’s identification number is also used in maintaining 
a journal of his or her activities. Passwords, unfcrtu- 
nately, have many potentially damaging vulnerabilities. 
Some technical and managerial CDun termeasures that have been 
recommended by Courtney [8ef. 3: pp. 40 -43,], HB3 [Ref. 24; 
pp. 9 - 12], and Shaalcer 'Ref. 25: p, 30,] as appropriate to 
counteract the vulnerabilities of passwords are as follows. 

• Password Generation and Selection - Passwords should be 
comprised of a sufficient nuaber of characters and gener- 
ated in such a manner as to assure a degree of protection 
commmens urate with the value of the assets. They should 
be generated randomly, so that no associarion with a 
particular user can be detected. Beraan has suggested 
that password generation be based on the concept of a 
"virtual password" [Ref. 26: pp. 97-104]. The password 
is created at the time the user identifies himself or 
herself to the system and is based on the user's identi- 
fication number, social security number, and, in some 
cases, the user's department number. Ref. 26 also 
provides a sample algorithm that is suitable for gener- 
ating a "virtual password." 

• Password Distribution - Passwords for accessing the ADP 
system should be distributed only to users meering the 
ADP system's need-to-know and need-to- utilize criteria. 
The use cf a unique password by a user to access the the 
ADP system, the application system, and the network is 
endorsed by industry and is used by several command and 
control ADP systems within the Navy. This hierarchy of 
access requires that the user be authenticated at xhe 
system, application, and network levels. Each password 
should be personally delivered to a user with instruc- 
tions to memorize it, or it should be transmitted over a 
secured communication path to the user. If the password 
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is transmitted, tben either the user should immediately 
initiate a password change or, if implemented, an auto- 
matic password change routine should be invoked after 
initial log-on. 

• Password Storage PrutectiDa - Passwords are usually 

stored in a file located in main memory. The file is 
therefore vulnerable to tampering. To protect the pass- 
word file, an appropriate countermeasure is to either 
encrypt the file using the Data Encryption Standard (see 
Ref. 27) or pass the file through a har d-to-in vert trans- 
formation algorithm. Tie algorithm should be 

sufficiently difficult to prevent a code breaker from 
successfully breaking the cede with a reasonable amount 
of time and resources. 

• Password Usage Protection - Passwords entered via CRT or 

printing terminals should be prevented from display by 
masking the keyboard response. Additionally, a security 
alarm or a terminal lockout should be generated automati- 
cally after a specific number of unsuccessful access 
attempts or a specific time delay has elapsed since the 
last access attempt. In order to uncover possible unau- 
thorized usage of a password, it is suggested that each 
user be shown a record of the most recent accesses under 
his or her password upon log-on. To protect passwords 
during a commu nic atio ns transmission, an appropriate 
countermeasure is to use either an encryption technique 
or a protected communications distribution system 
[Ref. 10: p. F-39 ]. The system should also respond in 

the same manner to a valid identification number and 
invalid password, as it does to an invalid identification 
number and invalid password. This prevents a user, who is 
attempting an unauthorized access, to know whether the 
identification number is valid or not. 
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• Password Lifetiais - Passwords should be changed periodi- 
cally, since the likelihood of them being surreptitiously 
discovered increases with tine. Also, if a password is 
compromised or a user's access right is revoked, then the 
password should be immediately invalidated, 

2, Device Authentication 

Besides authenticating an authorized user, the AD? 
system should be able to uniquely recognize devices rhat are 
requesting services. This is particularly important when 
evaluating the threats posed b/ remote or portable termi- 
nals. An appropriate technical countermeasure is to require 
each device to be equipped with circuitry which will respond 
automatically to an interrogation command and rransai- an 
identification code. This handshaking between the AD? 
system and the remote device is accomplished either by an 
exchange of identification codes or by the successful execu- 
tion of a particular algorithm. The identification cods, 
also called a security code, should identify the particular 
device and be unique within the system. This permits a 
system-wide journal to maintain a log of accesses by device. 
The device’s circuitry should be protected in tamper- 
resistant housing, and, if the amount of protection 
warrants, the transmission should be protected by encryption 
or a protected communications distribution sysrem. 
[Ref. 24: p.22] 

If the system services devices which are not 
directly connected, it should be capable of initiating a 
call-back procedure that verifies the device's identity. 
This call-back procedure makes use of a remote access list, 
which must include device identification codes and a sat of 
authorized logical addresses or telephone numbers from which 
each device can originate a request. Implementing either of 
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these countermeasures will enable the ADP system to guard 
against an unauthorized device nasguerading as an authorized 
one . 



B. ACCESS CONTROL 

Access control so unterraeasi r es enable properly identi- 
fied users to access only those system resources for which 
authorization has been granted. Traditionally, authoriza- 
tion in conventional systems has meant that every system 
element is automatio ally granted access to every other 
system element, unless speoifically prohibited. In 
contrast, ADP systems base authorization on the "least 
privilege" principle, which states that a system element is 
expressly prohibited from accessing another element, unless 
authorization has been explicitly granted. This principle 
limits the damage that can result from error or malicious 
attack and restricts the access of system elements to a 
protective domain. 

Before discussing the design considerations for access 
control mechanisms, an explanation is required of what 
constitutes a subject and an object. A subject is an active 
entity in the ADP system that corresponds to a process or 
task acting on behalf of a user or the operating system. An 
object is either a software created entity which represents 
a collection of information (a.g., file, directory, or 
program) or a hardware recognizable entity like a terminal 
or special-purpose register. An access matrix conceptually 
represents what subjects can access what objects and speci- 
fies what access rights (read, write, delete, etc.) the 
subjects have to the objects. 
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I* A£££§§ ContEDl Desian Qd isider at ions 

The design of accsss ooatrol mechanisms is based on 
three considerations: [Ref. 28: pp. 192-217] 

• Access Hierarchies, which automatically give privileged 
subjects a superset of the access rights of nonpr ivil eged 
subjects. Privileged subjects are those active entiries 
of a two-state machine that operate in the supervisor 
domain. A subject operating in this domain has access to 
all objects in the system, can creare and delete objects, 
initiate and terminate user processes, and execute privi- 
leged instructions not available to subjects operating in 
the user domain (no npri vilege d subjects). For example, 
processes in the supervisor domain can change process 
status words and sxecute I/D instructions, while those in 
the user domain can only request those services be 
provided on their behalf. 

• Authorization Lists, which associate with each object 
those subjects which have access rights to it. These 
lists are typically used to protect owned objecns such as 
files and data. 

• Capabilities, which are like "tickets'* for objects; 
possession of a capability unconditionally authorizes the 
holder access for all associated objects. In other 
words, associated with each subject is a capabilities 
list which specifies the sabject's access rights to a 
list of objects. 

Access control can be segregated into several 
levels: system, subsystem, file, record, or field, where the 
subject's access rights are delineated at each level. With 
an access control mechanism designed to mediate accesses 
down to the field level, a greater likelihood exists of 
detecting a violation or misuse of system resources. 
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However, such a design significantly increases the number 
and types of accesses to be verified and generally leads to 
a degradation of system performance. 

2. Acc^s Control Implementation 

Access control countermeasures are implemented by 
software routines which execute in the supervisor domain, 
and are invoked by the file manager to grant or deny access 
when symbolic references are made between subjects and 
objects. As shown in Figure 4.1, the access control marrix 
identifies all subjects and objects in the system and 
defines their relationship. If the matrix were directly 
implemented, the time required to validate an access request 
could be unreasonable due to the potentially large number of 
empty spaces in the matrix. 

Depending on the system software design, the access 
control countermeasure, which enforces the relationships 
depic-ed in the matrix, can be implemented in different 
ways. One approach is no organize and store the access 
relationship from the subject's perspective, thereby elimi- 
nating empty spaces in the matrix. This perspective, which 
is called a capability-list orientation, maintains a capa- 
bility list for each subject giving both the subject's 
access rights and its related objects. The advantage of 
this approach is that once the subject's capability list is 
retrieved, the time required to validate subsequent access 
requests is minimal. [Ref. 23: pp. 207-218, Ref. 29: p. 
169] 

A second approach is to organize and store the rela- 
tionship from the object's perspective, where once again the 
c-mpty spaces are eliminated. This perspective, which is 
called an authorization-list orientation, maintains with 
each object a list of authorized subjects and their respec- 
tive access rights. The advantage of this approach is that 
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Figure 4.1 Access Control Matrix. 

once an object has been requested, further requests for the 
same object can be readily processed. [Ref. 29: p, 169] 

Each of the approaches discussed above has a serious 
maintenance problem. For example, when an object is removed 
or a subject’s access rights are changed, an exhaustive 
search is needed to update all affected entries. This is 
very time consuming when using a list based strictly on 
either capabilities or authorisations. Ref. 29 recommends 
an authority-item approach to overcome this deficiency. The 
approach is explained as a method for 

organizing the access control information into authority 
items, each of which corresponds to a user (subject). 
Furthermore, every resource (object) in an authority 
item is linked with the same resources (objects) in 
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other authority items. Thus, the authority item 

approach supports capability lists directly and access 
(authorization) lists indirectly through linkages. In 
this way, search of authority items due to removal, 
changes, and suspensions need not be exhaustive. 

[Ref. 29: p. 170] 



Regardless of the approached pursued, the overriding 
consideration is to reduce the time needed to grant or deny 
an access request and to provide a flexible mechanism that 
can readily adapt to the dynamic interaction between 
subjects and objects. For additional information on 

different i nplementati ons of access control countermeasures, 
the works by Stiegler (1979), Buttar (1930) and Gladney 

(1975) are recommended. 

The implementation approaches presented above were 
directed towards alternative design proposals for the access 
control function. These same considerations apply equally 
as well to the design of a data base management system since 
it also is concerned with ensuring that only authorized 
users gain access to resources [Ref. 30: pp. 229-252]. 

C. SORVEILLANCE 

The surveillance countermeasure detects and reacts 

appropriately to any internal system activiry that it has 
determined may constitute a security threat. In order to 
determine the source of this threat, the system must have a 
means of achieving strict personal accountability for ail 
users (unique assignment of identification numbers). k 
surveillance countermeasure needs the capability to concur- 
rently perform two functions: threat monitoring and 

security auditing. For the countermeasure to be effective, 
the events to be monitored and logged must be approved 
during the design of the ADP system and the capability 
implemented prior to its operational use. The surveillance 
countermeasure is usually implemented to operate in the 
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privileged domain and, like all other system sofrware, 
requires protection from unautharized modification, destruc- 
tion, disclosure, or denial of service. 

Threat monitoring is the real-time detection of a 
successful or attempted penetration of the ADP system. The 
threat monitor observes all user and system interactions to 
ensure that the proper actions and responses are being 
exchanged. If the monitor detects a security violation 
(penetration attack), it must record the event and take some 
automatic action, depending upon the severity and effect of 
the violation. This action could range from printing a 
security alert message on the operator’s console to sounding 
an alarm in the ADP Security Officer’s location. In 
designing the monitor, one must address what information, if 
any, should be returaed to the aser attempting to compromise 
the system and what the disposition of the user’s program 
should be if execution had been initiated. 

Security auditing concerns the logging, analyzing, and 
reporting of security -related events, in particular, any 
attempted or successful security violation. The logging 
function collects and records in a historical file such 
things as the user’s identification number and time of 
log-on, the devices from wiich the user has entered 
commands, programs, and files, and any other system data 
unique to the particaLar user session (e.g., general regis- 
ters, memory bounds, location of virtaal memory table) 
[Ref. 29: p. 166]. The logs are used to provide an audit 
trail of system activity and to assist in the investigation 
of recorded security violations. 

Analyzing and reporting of security-related events is a 
joint responsibility of the surveillance software counter- 
measure and the ADP Security Dfficer. The countermeasure is 
normally designed to maintain statisrics on security-related 
events and to prepare standardize reports on such events. 
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while it is the ADP Security Officer that interprets these 
products and takes appropriate ictions to correct the docu- 
mented vulnerabilities. It is intended that a surveillance 
countermeasure will act as an effective psychological deter- 
rent to the user who might otherwise consider abusing his or 
her privileges. 

D. INTEGRITY 

Integrity is the juality of protection that assures that 
the ADP system works in a cohesive and predictable manner 
regardless of the operating conditions, that technical coun- 
termeasures are affective ia maintaining the desired 
security level, and that the AD? system is adequately 
protected from the occurrence aad impact of errors [Ref. 31: 
pp. 15-17-]. Countermeasures for enforcing a system 
integrity policy include controls for the internal (hardware 
and software) system, processing, and system errors. The 
technical countermeasures presented in the following 
sections have been synopsized from Refs. 29, 32 and 33. The 
listing is by no means exhaustive, rather it repesents 
industry’s judgement of the most effective countermeasures 
for today’s hardware and software. These countermeasures 
are not usually identified explicitly as security mechan- 
isms, but are often present for assuring a high degree of 
system reliability. 

System Co ntrols 

In today’s multi programming and multiprocessing ADP 
systems, many users are concurrently sharing system 
resources (memory, CP3, and I/O devices) and programs. The 
multiplexing of these elements among many users has created 
a need to isolate (s elf- protect) user programs from one 
another, the system software, and the other system 
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resources. This isolation of elements is achievsl by 
implementing various technical countermeasures that provide 
for main memory protection, dual execution states, and 
virtual machine monitors. 

a. Main Memory Protection 

Main memory protection concerns the ability to 
protect partitions or porrions of main memory from unwar- 
ranted access by user programs. Main memory is usually 
divided into mutually exclusive areas that are managed by 
the system software. The system software loads rhese areas 
with as many user programs as can be efficiently serviced. 
In previous generations, this meant bringing in a user 
program, executing it for a period of time, suspending its 
execution, and loading in another user program. This swap- 
ping continued usually via a round robin servicing scheme 
until the user program had finished execution. This is no 
longer judged as an efficient use of main memory. 

To overcome this inefficiency, a new architec- 
ture developed which supports a virtual memory capability. 
The important characteristic of a virtual memory architec- 
ture is that the address space of a user program is 
partitioned into a set of independently allocated units, 
some of which are main memory resident during program execu- 
tion, and some of which are not. With chis new approach, 
the system software Loads only units needed for execution, 
hence a greater number of users can be serviced and memory 
usage is mors efficient. [Ref. 32: pp, 32-33] 

When the AD? system does not permit concurrent 
sharing of system resources or processes by multiple users, 
the traditional main memory protection countermeasures of 
base and bound registers or locks and keys are sufficient to 
enforce an isolation policy. Memory base and bound regis- 
ters are set by the system software to specify the valid 
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upper and lower maia memory addresses for the currently 
executing process. kny attempt by the process to fetch from 
or store to an address outside these bounds generates an 
interrrupt to the system software. When a different process 
is brought in, the base and bound registers are changed to 
describe the new process* memory area. A lock and key coun- 
termeasure is implemented by marking each location in main 
memory with a lock and each program with a key. When the 
user program is brought into mala memory for execution, the 
system software compares the key with the locks and unlocks 
only those areas matched by the program's key. Each fetch 
and store is automatically examined by the hardware to 
confirm that the key and lock match. 

When the ADP system permits resource sharing, 
these traditional countermeasures are not adequate because 
they allow programs with different protection attributes to 
concurrently access the same area of main memory. Ref. 29 
recommends a solution to this problem that incorporates the 
protection attributes and size contraints in the address 
translation table. This table is used by the system soft- 
ware to map the virtual addresses of a user program into the 
physical addresses needed in main memory. [Ref. 29: pp. 
108-114] 

Some additional countermeasures that are needed 
to protect ADP systems which process sensitive business data 
are as follows. 



• Ability to scrub (zero outi residue from main and secon- 
dary memory before reallocation to another user process. 

• A memory write protection feature that prevents one 
program from overwriting another. Any attempt to write 
generates a system interrupt. 
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b. Dual Exs^utioa Statss 

The dual exacutiaa states of privileged and 
nonprivileg ed allow the DPD to maintain the two execution 
domains of supervisor and user. The system software 

executes in the supervisor donain, thus it is permitted 
immediate access to all system resources, including the 
ability to execute privilaged CPU and I/O instructions. On 
the other hand, the user's process executes in the user 
domain and any attempts to execute a privileged instruction 
is automatically trapped by the CPU, Basically, this action 
generates an interrupt whicn signals the CPU to change to 
the privileged stats and allows the system software to 
execute the instruction on behalf of the user process. This 
countermeasure is available on almost all current ADP 
systems. 



c. Virtual Machine Monitors 

The implementation of virtual machine monitors 
allows each user program to have its own virtual machine 
uniquely configured for its needs. The virtual monitor is 
considered to be a functionally £221El§te machine with its 
own virtual CPU, memory, I/D channels, devices, and any 
other virtual resources requested. The only thing it lacks 
to execute a user program is the physical CPU. The physical 
CPU is allocated between virtual monitors, working a 
specific amount of time for each virtual CPU according to a 
specified strategy. This allows for the time-multiplexing 
of each virtual monitor on the actual hardware and the 
dynamic reconfiguration of the system to satisfy the needs 
of a user program. Since each user process is contained in 
a specifically configured virtual environment, any attempt 
to access a system resource outside that environment auto- 
matically generates a system interrupt. Therefore virtual 
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machine monitors also rontribute to an isolation (self 
protection) security policy. 

2* P£ 2 cessing. Controls 



Processing controls are mainly limited to adminis- 
trative countermeasures sued as standard operating 
procedures and soft»»are engineering practices that indi- 
rectly protect the ADP sysrem and enhance the effectiveness 
of the technical count ermeasuree . Some of the controls that 
should be considered as possible candidates are as follows. 






Users should be restricted to programming only in 
higher-level languages. 

Modifications to system and application software should 
be implemented by a two-person control strategy. Two 
persons must sign off on all changes to the system soft- 
ware before the changes are made in the operational 
version . 

A Configuration Management Plan which addresses software 
development and maintenance procedures should be 
implemented. 

A Contingency Plan which describes “he securiry proce- 
dures for responding to abnormal operating conditions 
should be established, published, and periodically 
tested. 



3. Sys,;^m Error Controls 

System errors, also called failures, result in a 
degraded or unknown performance level and can be caused by 
hardware malfunctions, software errors, or operator errors. 
Hardware malfunctions are caused by such things as the CPO, 
memory parity, I/O interface and communication line, or 
power failure. Software errors are concerned with both 
operating and application systems deficiencies and are 
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attributed to incomplate design specifications and/or imple- 
mentation. And lastly, operator errors result from either 
badly defined operating procedures or simple human error. 
[Ref. 33: pp. 104-105] 

In developing countermeasures to protect against 
these three types of errors, the designer must consider 
error prevention, detection and recovery. Error prevention 
is usually satisfied by providing sufficient redundancy so 
that a component failure doss not degrade performance. 
Error detection requires the ADP system to be capable of 
recognizing potential hardware and software malfunctions 
before the entire system aalts. Error recovery relarss to 
continuation of system functions after an error has occured. 
Recovery can be affected at several levels, depending upon 
the severity and impact of the error. For example, if an 
error could crash the system, tie recovery would be a system 
restart; or if a program attempted to read past the end-of- 
file, the recovery would entail an error message to the 
user. Some countermeasures than have been suggested by 
Carroll [Ref. 20: pp. 265-237] and TRW Systems, Inc. 
[Ref. 33: pp. 129-173] as effective in counteracting system 
errors are: 

• hierarchically designed fault- tolerant AD? systems 

• redundancy of hardware and software components 

• automatic backup hardware switchover 

• transfer of critical system functions from software to 
firmware or hardware 

• dynamic checking of the system’s operating state with 
appropriate recovery actions specified should an illegal 
state be detected 

• capability for logical consistency checks (e.g., simulta- 
nious interrupt prevention, device address and existence 
check, and time check on propagation of signals between 



31 



i 



devices) with appropriate recovery actions initiated 
should an inconsistency be realized 

• capability for selective termination, graceful degrada- 
tion, automatic initiation of diagnostics, and graded 
(warm/cold) restarts 

• memory parity and address validation 

• replication of critical system files including data bases 
and audit logs 

• employment of data integrity controls such as: checks 

for reasonableness, consistency, and range, use of 
checksum totals aid parity during data transfers, and 
maintenance of a transaction journal 

• timing and sequence checks pertinent to I/O operations 
(e. g. , I/O instruction execution and I/O transmission) 
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7- RECOMMENDATIONS 



A. RECOMMENDED SPLICE FONCTIDNAL SECURITI MODULE 

This section provides recoaunended design specifications 
for a software Sacurity Hodula to be incorporated into the 
functional design of the SPLICE Local Area Networic (LAN), 
The specifications ace based upon the assumption that all 
data handled within the SPLICE LANs will be classified no 
higher than Sensitive Business Data. The design specifica- 
tions recommended ia this section satisfy the protection 
requirements set forth in Refs. 10 and 11. 

As discussed earlier, a complex data processing environ- 
ment like SPLICE is usually protected by enforcing the four 
ADP security policies of authentication, access control, 
surveillance, and integrity. The SPLICE Security Module has 
been designed as a collection of submodules, with a recom- 
mended software submodule foe each policy area except 
integrity. The integrity requirements of SPLICE have 
already been addressed in Ref. 13 and, if implemented, will 
be adequate. The integrity requirements address such things 
as memory protection features, change control procedures, 
memory parity, data integrity controls, and system consis- 
tency checks. The recommended security module is 
specifically tailored to satisfy the security requirements 
of the SPLICE LAN and should not be construed as being 
endorsed for all such ea vironm ents. The terms used to 
describe the Security Module and its interactions with the 
other functional modules of the SPLICE LAN have been taken 
from Ref. 34. 
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The functions of the SPLICE Security Module are as 

follows: 

• Authentication of the user when accessing the SPLICE 
Configur ation. 

• Authentication of terminals and peripheral devices when 
requesting or performing a service. 

• Maintenance of an access control mechanism which enforces 
the access rights as prescribed for subjects and objects 
of the local SPLICE Configuration and validates requests 
for access to the SPLICE LAN and the Defence Data 
Network. 

• Maintenance of an online secarity auditing mechanism that 
logs appropriate security related information required to 
support subsequent analysis efforts. 



In order to enforce an authentication policy, 
authorized use of SPLICE resources must be controlled by 
both an administrative and a software countermeasure. The 
administrative countermeasure requires that each user and 
device be uniquely identifiable within the SPLICE LAN. The 
software countermeasure necessitates the design of software 
submodules which function to identify users, terminals, and 
peripherals . 

Chapter IV presented in detail numerous mechanisms 
considered effective in protecting a password authentication 
countermeasure. It is recommended that those mechanisms be 
evaluated for their applicability to the detailed design of 
the authentication submodule. 
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a. Aiithentica tioQ of Tsrminals and Users 

The softi^are submodule for authenticating termi- 
nals and users should be invoked by the Front End Processor 
(FEP) Module when the user initially attempts to log on to 
the local SPLICE Configuration (local system). It is 
assumed that the FEP Module can recognize when a user is 
logging on to the local system and that it can invoke the 
submodule when appropriate. 

The terminal's identity should be checked by 
requiring the terminal to transmit a security code in 
response to an interrogation command. The code is then 
matched against a table of authorized terminal security 
codes. If a march is found, the logon procedure continues. 
Otherwise, the security auditing submodule (to be addressed 
later) is invoked and appropriate actions for responding to 
a security violation are taken. After the terminal's iden- 
tity is verified, the user's identification number and 
password are checked in a similar manner. If a match is 
found, the logon procedure is completed and control passed 
back to the FEP Module. If no match is found, the security 
auditing submodule is invoked as before and control is 
passed back to the FSP Module after appropriate actions have 
been taken. 

It is recommended that the authentication 
submodule fcr terminals and users be located in the same 
physical machine as the FEP Module for each local system. 
This recommendation is based on the need to restrict a 
nonverified terminal and user to as little of the local 
system as feasible. This submodule will only be invoked 
when a user (local, remote or satellite) initially logs on 
to the local system. 
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b. Authentication of Peripherals 

The authentication submodule for verifying the 
identity of a peripheral device has not been examined due to 
the lack of detailed design specifications concerning how 
the Peripheral Management (P!l> Module interacts with the 
local system. Once the design has been completed, it is 
recommended that the countermeasures presented in Chapter IV 
Section A. 2 be reviewed for their applicability. 

2. h£.Q.3§.§. Control 

After the user’s identity is verified, the FEP 
Module forwards all subsequent nser messages to the Terminal 
Management (TM) Module. The TM Module responds by 
requesting that the Session Services (SS) Module establish 
and maintain a user session. After a session has beer, 
established, the SS Module examines each user request and 
invokes the appropriate generalized functional module needed 
for accomplishing the task requested. It is recommended 
that the SS Module lavoke the access control submodule to 
validate the user's authorization rights before it invokes 
any other functional nodule on behalf of the user. 

The access control submodule should perform two 
types of authorization control. First, if the user task 
requests access to the SPLICE LAN or the Defense Data 
Network, the access control submodule should ensure that the 
user has been authorized such an access. The second type of 
ccnxrol involves granting or denying a user (either local, 
remote or satellite) access to a local system object such as 
a file, directory, or peripheral device to perform some 
action such as read, write or execute on that particular 
object. If the request is not allowed, the security 
auditing submodule is invoked and appropriate action is 
taken. 
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The design of the access control submodule should be 
based on the authority item technique presented in Ref. 29. 
This design specification reduces the time required to grant 
a user author iration request and allows authority items to 
be easily modified when changes are made to the authoriza- 
tion rights of a user (subjecti or the access capabilities 
of an object. The implementation of rhis countermeasure 

requires that the authorization rights of users and access 
capabilities of objects be explicitly defined and maintained 
online for use by the access control submodule. It is 
recommended that the access control submodule be colocated 
with the SS Module to minimize the time required no validate 
a user's au thorizatinn . 

3* Sur yei l lance 

In order to enforce a surveillance policy, it is 
recommended that a security auditing submodule be incorpo- 
rated in the design of the SPLICE Security Module. Mo 
particular location far this submodule is recommended, as it 
could be a candidate for relocating from one physical 
machine to another as necessary to improve the overall 
performance of the SPLICE Configuration. This submodule 

will be invoked by the TM Module, the S3 Module, the PM 

Module, and any other module which can recognize a security 
violation or system error. Ihe appropriate actions for the 
submodule to take when invoked are to log the event, to 
notify the central system operator that an error or viola- 
tion has occurred, and if the error or violation is severe 

enough, the user’s log-on or session should be terminated. 
The security-related information recorded by this submodule 
should include at a minimum the following. 

• A system access log which identifies who accessed the 
system, what terminal the access was made from, whether 
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and the date and 



the access attempt was successful, and the date and time 
it occurred. 

An input/output log which identifies who requested the 
service, what function (read, write, enter, print) was 
provided, whether the function was successful, and the 
date and time it occurred. 

A processing log which records appropriate security- 
related information about system errors and security 
vio latio ns. 



B. OTHER RECOMMENDED SPLICE SESORITY MEASORES 

It is recommended that NAVSOPINST 5513. 6A be revised and 
reissued to accomodare the miainum mandatory countermeasures 
listed in Appendix J of Ref. 13, which was issued subsequent 
to NAVSUPINST 5510. 6A. This would allow the mandatory coun- 
termeasures to be included by reference in the next version 
of the SPLICE Security and Risk Analysis Plan [Ref. 11]- 

The ’’SPLICE umbrella” contains many software products 
which are being developed by Central Design Activities for 
distribution to multiple activities. It is recommended that 
the SPLICE Project Officer insure that each software product 



is certified in ac 


cor dance with 


OPNAVINST 5239. 1A 


prior to 


distribution [Ref. 


13: p. 3-1]. 






In the design 


of software 


products, the 


soft ware 


controls listed in 


Appendix I of 


Ref. 10 must be 


inco r ?o- 


rated. It should 


also be noted 


that contractor 


devsloped 



software and countermeasures are also subject to the 
requirements of Ref. 10. 

It is recommeded that the following actions be taken to 
help insure that the risk in SPLICE is quantified and 
managed at an acceptable level. 

• A Network ADP security Officer should be designated early 
in the lifecycle of the SPLICE Project. The individual 
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so designated should be given a position high enough in 
the project organization ani appropriate authority and 
resources to manage the SPLIZE Risk Analysis Program and 
effect the necessary design changes and operational 
requirements. 

• The Network ADP Security Officer should develop and main- 

tain a comprehensive checklist of threats which are 
potentially present at any SPLICE activity. The reader 
is invited to review the works of Martin (1973), N3S FIPS 
31 (1974), Ref. 23 , and Ref. 22 for recommended lists of 

threats. The checklist should be made available to 
activity risk analysis teams. 

• The Network ADP Security Officer should be given cogni- 
zance of all activity security incident reports [Ref- 10: 
p. 8-2] in order to identify and monitor vulnerabilities 
which potentially exist in the SPLICE Network. 

• A risk management training program should be established 
to provide a consistent Risk Management Program 
throughout the SPLICE Network. A list of responsibili- 
ties for ADP security training is provided in Chapter 10 
of Ref. 10. 

• The appropriate Inspector Seneral review program for 

every SPLICE activity should incorporate a security 
review, as defined in OPSliVINST 5239. 1A [Ref. 10: p. 

8-1 ]. 

C. FUTURE RESEARCH QUESTIONS 

S'^cu ritv lodul^ Specif icat ions 

This thesis provides a formal program for risk 
management, but does not attempt to quantify the risk in any 
particular activity. Additional research should be accom- 
plished in at least one of several ways. The risk of 
operating can be estimated by simulating a "typical SPLICE 
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activity." This would require complete enumeration of all 
assets in the seven resource citegories, and a listing of 
all "potential" threats facing a SPLICE activity. 

Another research methed would be to examine an 
existing Navy activity that is designated to become a SPLICE 
activity. By evaluating the changes in the data processing 
environment due to the SPLICE configuration, their impact on 
the ADP security posture of the activity can be properly 
examined . 

By using one of these research methods, the recom- 
mended Security Functional Module can be valida-ed and, if 
needed, additional countermeasures can be specified for in 
the design of the SPLICE software or implemented at the 
operational SPLICE activities. 

2* Cri^gue of Risk Management Program 

The Risk Management Program models presented in 
Chapter 3 formalize the concepts proposed by Courtney 
[Ref. 3], NBS [Ref. 17], and Fitzgerald [Ref. 19], and 
adopted by the Navy in the DON ADP Security Program 
[Ref. 10]. Although the models presented hers reflect the 
established concepts of tne various references, no attempt 
has been mads to analyze the validity of the concepts. 

Both the Asset Loss Determination Model and rhe 
Threat and Vulnerability Evaluation Model are essentially 
exponential utility functions, which exhibit decreasing 
marginal utility, '4ith respect to asset losses, this 
implies that an asset loss of SI, 000 with a total asset loss 
level of $10,000 is not as significant as an asser loss of 
$1,000 when the asset loss level is at 3100,000. A simple 
question arises in chis reasoning. To a computer sysrem 
user, is the tenth day of doing without service less impor- 
tant than the first or second? Likewise, is losing the use 
of a tape drive less significant if you have already lost 
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five tape drives thaa it is whea you have lost none? Thera 
may exist an argumant that ths marginal utility should 
increase with increasing asset losses. 

In threat an! vulnerability evaluation, less signi- 
ficance is similarly placed on narginal risk as the activity 
becomes more vulnerable or more threats are present. Is the 
risk of a fourth or fifth attaok not as significant as the 
second or third? 

Finally, the Navy's risk management decision 
problem should be more fully modeled. Currently explicit 
constraints are plaoed on the activity manager by the DAA 
who sets a maximum acceptable Total ALE. Although not docu- 
mented in the Navy program, the setting of the maximum 
acceptable Total ALE is dona by use of the DAA’s utility 
function. Certainly this choice is made in light of ocher 
investment alternati/e s, and with regard to the Navy system 
of incentives, rewards, and penalties. 
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APPENDIX A 
LIST OF AERONYHS 


ADP 


Aatomatic Data Processing (See EDP) 


ADPSO 


Automatic Data Processing Security 

Df ficer 


ADPSSO 


Automatic Data Processing System 

Security Dfficer 


ALE 


Annual Loss Expectancy 


ARPANET 


Advanced Research Projecrs Agency 

N e twor k 


CPU 


Central Processing Unit 


CRC 


Cyclical Redundancy Check 


CRT 


lathode Ray Tube 


DA A 


Designated Approving Authority 


DDN 


Defense Data Network 


DES 


Data Encryption Standard 


FIPS 


Federal Information Processing Standard 
(National Bureau of Standards) 


GAO 


General Accounting Office 


I/O 


I.a put/Output 


IP 


Internet Protocol 


IPLI 


Internet Private Line Interface 


LCN 


Local Comoutsr Network 
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MC 


Monitoring Cen-er 


NBS 


National Bucaau of Standards 


NSO 


Natwork Sacarity Officer 


OHB 


Office of Management and Budget 


SPLIC2 


Stock Point Logistics Integrated 

Communications Environasnr 


STSE 


Security rest and Evaluation 


TASO 


Terminal Area Security Officer 


TCP 


Transmission Control Protocol 


VMM 


Virtual Machine Monitor 
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APPENDIX B 
DEFINITIONS 



The majority of the defiaitions contained herein are 
taken from the Department of the Navy Automatic Data 
Processing Security Program Manual, OPNAVINST 523 9. 1A 
[Ref. 10]. All defiaitions not from OPNAVINST 5239. 1A are 
referenced . 

ACCEPTABLE LEVEL OP RISK. A judicious and carefully consid- 
ered assessment by the appropriate Designa-ed Approving 
Authority (DAA) that an automatic dara processing (ADP) 
activity or network meets the minimum requirements of appli- 
cable security directives and the provisions of OPNAVINST 
5239.1 A. The assessment should take into account the value 
of ADP assets; threats and vulnerabilities; countermeasures 
and their efficacy in compensating for vulnerabilities; and 
operational requirements. 

ACCESS. The ability and the means to approach, communicate 
with (input to or receive output from) , or otherwise make 
use of any material or component in an ADP system. 
Personnel only receiving computer output products from the 
ADP system and not inputting to or otherwise interacting 
with the system (i.e. , no "hands on" or other direct input 
or inquiry capabilityt are not considered to have ADP system 
access and are accordingly not subject to the personnel 
security requirements of OPNAVINST 5239. 1A. Such output 
products, however, shall either be reviewed prior to dissem- 
ination or otherwise determined to be properly identified as 
to content and classification. * Ref. 35] 
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ACCESS AUTHORIZATION. PasswDci and/or U3sr id required to 
meet security restrictions for the resource being accessed. 
[Ref, 13] 

ACCREDITATION. A policy decision by the responsible DAA 
resulting in a formal declaration that appropriate security 
countermeasures have been properly implemented for the ADP 
activity or network, so that the activity or network is 
operating at an acceptable level of risk. The accreditation 
should state the mode of operation and any operating limita- 
tions applicable to the AOP activity or network. 

ADMINISTRATIVE SECURITY. The management constraints; opera- 
tional, administrative, and accountability procedures; and 
supplemental conrrols established to provide an accepoable 
level of protection for data. Synonymous with procedural 
security. [Ref. 35] 

ADP ACTIVITY. Any organizational entity with responsibili- 
ties for developing, operating, or maintaining an ADP system 
or network. 

ADP SECURITY. Measures required to protect against unau- 
thorized (accidental or intentional) disclosure, 
modification, or destruction of AD? systems and data, and 
denial of service -o process data. AD? security includes 
consideration of all hardware/software functions, character- 
istics, and/or features; operational procedures, 
acccuntabi 1 ity procedures, aid access controls at the 
central computer facility, remote computer, and terminal 
facilities; management constraints; physical structures and 
devices; and personnel and conaunication controls needed to 
provide an acceptable level of risk for the ADP system and 
for the data or information contained in the system. 
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ADP SECURITY STAFF. Individuals assigned and functioning as 
action officials for ADP security within their respective 
organization: 

ADP Security Officer (ADPSDt 

ADP Systems Security jfficec (ADPSSO) 

Network Security Dfficer fNSD) 

Terminal Area Security Officer (TASO) 

Office Information System Securiry Officer (OISSO) 

ADP SYSTEM. An assembly of computer equipment, facilities, 
personnel, software, and procedures configured for the 
purpose of classifying, sorting, calculating, computing, 
summarizing, storing and retrieving data and information 
with a minimum of anman intervention. An ADP system as 
defined for purposes of OPNA'/IMSr 5239. 1A is the totality of 
automatic data processing equipment. (ADPE) and includes: 

a. General and special purpose computers (e.g., digital, 
analog, or hybrid computer equipment) ; 

b. Commercially available components, those produced as a 
result of research and development, and the equivalent 
systems created from them, regardless of size, capacity, or 
price, which are utilized in the creation, collection, 
storage, processing, communication, display, or dissemina- 
tion of data; 

c. Auxiliary or accessorial equipment, such as data commu- 
nications terminals, source data automation recording 
equipment (e.g., optical character recognition equipment, 
paper tape typewriters, magnetic tape cartridge typewriters, 
and other data acquisition devices), data output equipment 
(e.g. digital plotters and computer output micrcfilmars) , 
etc., to be used in support of digital, analog, or hybrid 
computer equipment, either cable-connected, wire-connected, 
or self-standing; 

d. Electrical accounting machines used in conjunction with 
or independently of aigital, analog or hybrid computers; and 
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e. Computer equipment which sapports or is integral to a 
weapons system. [Ref. 35] 

ANNUAL LOSS EXPENTANC? (ALE). The ALE of an ADP system or 
activity is the expertea yearly dollar value loss from the 
harm to the system or activity by attacks against its 
assets . 

ASSET. Any software, data, hardware, administrative, phys- 
ical, comm unicatins, or par3:>nnel resource within an ADP 
system or activity. See ADP RESOURCES. 

ATTACK. The realization cf a tareat. How often a threat is 
realized depends on such facrors as the location, type, and 
value of information being processed. Thus, short of moving 
the sysrem or facility or radically changing its mission, 
there is usually no way that tie level of protection can 
affect the frequency of attack. The exceptions to this are 
certain human threars where effective security measures can 
have a deterrent effec*. The fact that an atrack is made 
does not necessarily n ean that it will succeed. The degree 
of success depends on the vulnerability of the system or 
activity and the ef fecriveness cf existing countermeasures. 

AUDIT. To conduct the independent review and examination of 
system records and activities ii order to test for adequacy 
of system controls, to ensure compliance with established 
policy and operational procedares, and to recommend any 
indicated changes in controls, policy, or procedures. 



d • Iii't c rn d 1 


Security Audit. 


An audit 


conducted by 


personnel responsible to the ma: 
being audited. 


lagement of 


the orgainzation 


b. External 


Security Audit. 


An audit 


conducted by an 


organization 
[Ref, 36] 


independent of 


the one 


being audited. 
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BROWSING. The act of searching through storage to locate or 
acquire information without necessarily knowing the exis- 
tence or the formar of the information being sought. 

CENTRAL COMPUTER FACILITY, One or more computers wirh their 
peripheral and storage units, central processing units, and 
communications equipment in a single controlled area. This 
does not include remote computer facilities, peripheral 
devices, or terminals which are located outside the single 
controlled area, even though they are connected zo the 
central computer facility by approved communication links. 
[Ref, 37] 



CENTRAL SYSTEM OPERATOR. A system user who by virtue of 
security access control authorization has access ro the user 
mode and the central system operator mole of the command 
interpreter. [Ref. 13] 

COHHUNICATICNS SECURITY. The protection resulting from all 
measures designed to deny unauthorized persons information 
of value which might be derived from the possession and 
study of telecommunications, or to mislead unauthorized 
persons in their interpretation of the results of such 
possesion and study. Also called COHSZC. Communications 
security includes cryptosecurity, transmission security, 
emission security, and physical security cf communications 
security materials and information. 

CONFIGURATION MANAGEMENT. The use cf procedures appropriate 
for controlling changes to a system's hardware and software 
structure for the purpose of insuring that such changes will 
not lead to decreased data security. 

CONTINGENCY PLANS, A plan for emergency response, backup 
operations, and post- disaster recovery maintained by an ADP 
activity as a part of its security program. A comprehensive 
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consistent statement of all the actions (plan) to be taken 
before, during, and after a iisaster (emergency condition), 
along with documenred, tested procedures which, if followed, 
will ensure the availability of critical ADP resources and 
which will facilitate maintaining the contimuity of opera- 
tions in an emergency situation. 

COUNTERMEASORE. See section II. A. 4. 



DATA INTEGRITY. The state that exists when computerized 
data is the same as that in the source documents and has not 
been exposed to accidental or intentional modification, 
disclosure, or destruction, "Ref, 36] 



DATA LEVEL, 

Level I. Classified data. 

Level II. Unclassified data reguiring special protection; 
for example. Privacy Act, For Official Use Only, technical 
documents restricted to limited distribution. 

Level III. All other unclassified data. 

DATA SECURITY. The protection of data from unauthorized 
(accidental or intentional) modif icaiton, destruction, or 
disclosure. [Ref. 35] 

DESIGNATED APPROVING AUTHORITY (DAA), An official assigned 
responsibility to accredit ADP elements, activities, and 
networks under the official's jurisdiction. 



ESCORT (S) . Duly designated personnel who have appropriate 
clearances and access authorizations for the material 
contained in the system and are sufficiently knowledgeable 
to understand the security inpLications of and to con-rol 
the activities and access of the individual being escorted. 
[Ref. 37] 
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HARDWARE SECURITY. Sompurer equipment features or devices 
used in an ADP system to preclude unauthorized accidental or 
intentional modification, disclasure, or destruction of ADP 
resources. 

MATERIAL. "Material” refers to data processed, stored, or 
used in and information generated by an ADP system regard- 
less of form or medium, e. g., programs, reports, data sets 
or files, records, and data elements. [Ref. 35] 

NEED-TO-KNO W. The necessity for access to, knowledge of, or 
possession of certain information required to carry out 
official duties. Responsibility for determining whether a 
person's duties require that possession of or access to such 
information and whet her the individual is authorized to 
receive it rests upon the individual having current posses- 
sion, knowledge, or control of the information involved and 
not upon the prospective recipi e n t (s) . 

NETWORK. The interconnection of two or more ADP central 
computer facilities that provides for the transfer or 
sharing of ADP resources. The ADP network consists of the 
central computer facilities, the remote terminals, the 
int erconnec tin g commun icat ion links, the front-end proces- 
sors, and the telecommunications systems. 

OPERATING SYSTEM (0/S> . An integrated collection of service 
routines for supervising the sequencing and processing of 
programs by a computer. Dperating systems control the allo- 
cation of resources to a user and their programs and play a 
central role in ensuring the secure operation of a computer 
system. Operating systems may perform debugging, input- 
output, accounting, resource allocation, compilation, 
storage assignment tasks, and other "system" related func- 
tions. Synonymous with terms such as "Monitor," 
"Executive," "Control Program," and "Supervisor." [Ref. 35] 
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PASSWORD. A protected word or string of characters that 
identifies cr authenticates a user for access to a specific 
resource such as a data set, file, or record. 

PERSONAL DATA. Data abojt an individual including, but not 
limited to, education, financial transactions, medical 
history, qualifications, service data, criminal or employ- 
ment history which ties the data to the individual's name, 
or an identifying number, symbol, or other identifying 
particular assigned to the indii^idual, such as a finger or 
voice print or a photograph. 

PERSONNEL SECURITY. The procedures established to ensure 
that each individual has a background which indicates a 
level of assurance of trustworthiness which is commensurate 
wirh the value of ADP resources which the individual will be 
able to access. 

PHYSICAL SECURITY. Paysical security is the protection of a 
material entity (property) from disruption of its safe and 
secure state and is concerned with physical measures 
designed to safeguard personnel, to pre/ent unauthorized 
access to equipment, facilities, material, and documents, 
and to safeguard them against espionage, sabotage, damage, 
and theft. 

a. The use of locks, badges, and similar measures to 
control access to the central computer facility. 

b. The measures reqnired for the protection of the struc- 
tures housing the central computer facility from damage by 
accident, fire, environmental hazards, loss of utilities, 
and unauthorized access, 

REVIEW AND APPROVAL. The process whereby information 
pertaining to the security and integrity of an ADP activity 
or network is collect e-d, anal/zed, and submitted to the 
appropriate DAA for acc redita ti on of the activity or 
network. 
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RESOURCE-SHARING COMPUTER SYSrEM. A computer system which 
uses its resources, including input/output (I/O) devices, 
storage, central processor (arithmetic and logic unirs) , 
control units, and software processing capabilities, ro 
enable one or more users to manipulate data and to process 
co-resident programs in an apparently simultaneous manner. 
The term includes systems with one or mors capabilities 
commonly referred to as timesharing, multiprogramming, 
multi-accessing, multi-processing, or concurrent processing. 
[Ref. 35] 

RISK. See section II. A. 1. 

RISK ANALYSIS (ASSESSMENT). An analysis of system assets 
and vulnerabilities to establish an expected less from 

certain events based on estimated probabilities of the 
occurrence of those events. The purpose of a risk assess- 
ment is to determine if countermeasures are adequate to 
reduce the probability of loss or the impact of loss to an 
acceptable level. 

SECURITY ACCESS CONSTRAINTS. The process and file access 
restrictions imposed by the security requirements. 
[Ref. 13] 

SECURITY FILE. File containing user ids and associated 
access constraints. [Ref. 13] 

SECURITY LOG. Data file containing violations of the 
security requirements. [Ref. 13] 

SECURITY OFFICER. Designated individual who is responsible 
for maintaining the security procedures for the 

installation. [Ref. 13] 

SECURITY INSPECTION. An examinarion of an AD? system to 
determine compliance with ADP security policy, procedures, 
and practices. 



132 



SECORITY SPECIFICiTID NS. A 
countermeasures required to 
network from unauthorized 
disclosure, modification, and 
of service. 



ietailed description of the 
protect an ADP activity or 
(accidental or intentional) 
destruction of data, or denial 



SECORITY TEST AND EVALOATIOH (STSE). An examination and 
analysis of the security features of an ADP activity or 
network as they have been applied in an operational environ- 
ment to determine the security posture of the activity or 
network upon which an accreditation can be based. 



SECORITY VIOLATION. Any attempt to gain access to the oper- 
ating system, the operating system files and executable 
modules, or system user files and executable modules. 
[Ref. 13] 

SENSITIVE BOSINESS DATA. Data which requires protection 
under Title 18, OSC 1905, and other data which by its nature 
requires controlled distribution or access for reasons other 
than the fact that it is classified or personal data. 
Sensitive Business Data is recognized in the following 
categories : 

a. For Official Use Only--Re qui.ring confidentiality of 
information derived from Inspector General, authority, or 
other investigative activity. 

b. Financial — Requiring protection to ensure the integrity 
of funds or other fiscal assets. 

c. Sensitive Manage a ent--Requi r ing protection ■^o defend 
against the loss of property, material, or supplies or to 
defend against the disruption of operations or normal 
management practices, etc. 

d. Proprietary — Requiring protection to protect data or 
information in conformance with a limited rights agreement 
or which is the exclusive property of a civilian cor Deration 
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or individual and which is on loan to the Government for 
evaluation or for its proper use in adjudicating contracts, 
e. Privileged — Reguiring protection for conformance with 
business standards or as reguired by law. (Sxample: 

Government- developed information involving the award of a 
contract . ) 

SPLICE CONFIGORATION. An integrated set of six hardware/ 
software systems required to achieve the functional, 
performance and capacity requirements of the SPLICE 

specifications. [Ref. 13] 

SPLICE LOCATION. One or more SPLICE configurations in the 
same geographical area (on the same Local Gomputer Network) 
connected to Government-furnished equipment and interfaces. 
[Ref. 13] 

SPLICE NETWORK- Provides the connectivity between geograph- 
ically distant SPLICE locations. Government furnished data 
communications lines shall connect the locations through 

common carrier lines and/or through a Government-furnished 

network. [Ref. 13] 

THREAT. See secrion II. A. 2. 

USER. A person or organization receiving products or 
services produced by a ADP system either by access to the 
system or by other means. 

OSER ID. Data element input to identify a system user and 
to label processing products resulting from the user- 
initiated processing. [Ref. 13] 

VDLNERABILITY See section II. A. 3. 
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APPENDIX C 

DEFENSE DATA NETWORK 



This Appendix provides a short summary of the Defense 
Data Network (DDN) . The souroe document used is the Defense 
Network Proaram Plan revised May 1982 [Ref. 38], 

A. GENERAL DESCRIPTION 

The DDN will be an integrated packet-switching data 
network designed to satisfy all DOD data networks require- 
ments projections through the 1990's. The DDN will take 
advantage of existing networks, notably the WWMCCS 
Intercomputer Network (WIN) and the Advanced Research 
Projects Agency Network (ARPANET) , and will be based 
primarily on ARPANET technology. Table X lists the standard 




TABLE X 

Standard DDN Components 



Switching node hardware 
Switching node software 
Cryptographic devices 

Host front-eni devices 
Host interface devices 
Mult iplexors 
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components to be used in the DDN. 

There will be 171 switching nodes located at about 85 
widely distributed sites. The switching node is a Bolt 
Baranek and Newman (B3N) C/30, a microprogrammed 
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minicomputer costing about $45,300 (including TEMPEST/HEHP 
protection) . The 3/30 is designed for unattended opera- 
tions. All switching nodes will be located on ailirary 
facilities and secured to at least the SECRET level. The 
network will have a principle System Monitoring Center 
(SMC), an alternate SMC, regional Monitoring Centers (MCs) 
in Europe and the Pacific, and MCs for each separate 
community. 

The DDN provides for increased survivability in several 
ways. The 171 fixed switching nodes and 9 fixed MCs will 
have HEMP protection (EM shielding, line isolation, and 
surge arresting protection). Sites with no backup power 
will be provided i n inte rrupta ble power supplies (UPS). 
There will be five prepositioned mobile reconstruction nodes 
equipped with HC capability. A dynamically adaptive routing 
algorithm will automatically rente traffic around congested, 
damaged, or destroyed switches and trunks. Additionally, a 
dense trunking grid will provide redundancy at all possible 
points in the network. 

There will be at least 99i5 availability between any pair 
of single-hcmed users. Critical subscribers will be dual- 
homed (a single access line to two switching nodes), 
providing an least 99.5% availability. Dual access lines to 
a single node can also be used. 

Precedence levels can be assigned by originating hosts 
and terminals, and will be used in the allocation of network 
resources. Switching nodes provide for four levels of 
precedence, with preemption of lower precedence communica- 
tions. Category I (FLASH and FLASH-OVERRIDE) communications 
will be processed in non-blocking mode exclusive of all 
other traffic modes and volumes. 

Communications errors will be minimized by the use of 
error detection and correction mechanisms. A Cyclical 
Redundancy Check (CRDi of 15 bits is associated with host 
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messages on the access lines aal packets on trunks. A 32 
bit CRC is used with S IP-compatible hosts. Additionally, 16 
bit checksums are provided on aa end-to-end basis within the 
switch subnetwork and on a user-to-user basis via the 
Transmission Control Protocol (TCP). Error detection and 
correction hardware is used in the switches for protecting 
against memory failures and for checksumming of critical 
data structures and portions of code. 

B. SPECIFIC DDN HARD» ARE/SOFTHARE 
’I* Swii^hing Node 

The BBN C/30 packet switching processor is a mulri- 
board, microprogrammed minicomputer, with 64k words of 
random access memory (RAMi , which supports a full range of 
synchronous and asynchronous I/O interfaces. Ihe C/30 soft- 
ware is the ARPANET Interface Message Processor (IMP) 
program which can be loaded locally (from a cassette) or 
downline loaded from a MC. The software provides the 
following functional capabilities: 

• Snore and forward traffic processing. 

• Hosn access and end-to-end traffic processing (with a 
variety of host access protocols, see p. 33 of Ref. 38). 

• Dynamic, adaptive, distributed routing which measures 
actual packet delays and routes individual packets along 
the least delay path. 

• Monitoring and control services. 

2* iHi^tnet Private Line liter face 

The Internet Private Line Interface (IPLI) is a 
security device, currently under development as part of the 
Gray Tree program, which will be used for end-to-end encryp- 
tion. It is composed of three functional units: a KG 84 
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cryptographic device and two MC53000 based packet processors 
(one on each side of the K3 34|. Figure C. 1 shows the 
placement of the IPLI with each host for end-to-end encryp- 
tion on the DDN. The software in each processor will be 
based on the CMOS operating system, with the basic functions 
necessary for the ODD standard internet environment and 
monitoring and control functions. The protocol interfaces 
conform to the DOD Standard Internet Protocol (IP). Since 
the packet processing occurs at the lower level of the IP, 
the TCP and other protocols which exist above the IP can be 
supported. 

Exclusive of the KG 8'4 , the estimated unit cost for 
production IPLIs (after FY84) in lots of 100 or more is 
$1 5,000. 

3. Min ill AC 

A mini-TAC is a terminal access device that allows a 
cluster of up to 1 6 synchronous and asynchronous terminals 
access to the network. It is logically equivalent to a 
network host and will use the same host-host protocols. The 
ARPANET- bas ed mini-TAO software allows a terminal to connect 
to hosts on the network. The nini-TAC software multiplexes 
all the terminal-host connections over a single link between 
it and the switching nods. Since Mini-TACs will not 

initially provide dial-up access, access will be over hard- 
wired lines and controlled by physical access control 
mea sures . 

The mini-TAC will be constructed around a Motorola 
MC68000 microprocessor with memory, 15 synchronous or 
asynchronous terminal ports, and multiple network interface 
ports (to allow dial-homing). The mini-TAC will meet 
TEMPEST and HEMP requirements. Mini-TACs will communicate 
with other network hosts using DOD standard TCP and IP. 
Terminal level support is provided via the Telnet protocol. 
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Figure C. 1 End-to-end Encryption. 
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The mini-TAC rfill be designed for unattended opera- 
tions. Control functions and hardware and software fault 
diagnosis can be dona remotely from a Monitoring Cenrer. 
Repair will be by board swapping. In quantities of 100, the 
production cost pec unit is estimated at $7500 plus $250 per 
port . 

C. SECURITY FEATURES 

The KS 84 crypto device will be used on all back 
bone trunks, on all access lines to classified hosts, and on 
access lines to sites that act as HCs for the unclassified 
community. Because all hosts will use the IPLI described 
above, communications on the trunks will be "super 
encrypted." The link encryption will conceal traffic 
patterns and monitoring reports, which might yield traffic 
analysis information. It also protects MC-switch control 
traffic, which is important since this traffic includes 
downline loading of sensitive switch software. 

2* Security kivsi Sep ar ation 

Separation of subscribers operating at different 
system high levels is provided by the use of IPLIs (at least 
one IPLI key for each different system high level) , creating 
at least one logical subnet for each security level. Since 
IP and subnet headers must be in the clear for packet 
processing within the switch, all switches are TEMPEST 
enclosed and in military facilities secured to at least the 
SECRET level. Establishment of logical subnets will guar- 
antee against delivery of communications to any subscriber 
outside the subnet. This guarantee against misdelivery will 
be used to protect statistical reporrs from being delivered 
to any hosts other than an MC. Each MC and the fake host in 
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each switch that co mini nica tes with the MC will be members of 
the logical subnet. i ddit ionally , only the SMC can retrieve 
and accumulate traffic statistics. 

Se£aration of Communities of Interest 

Communities of interest are subscriber groups which 
present an acceptable level or risk to each other and 
require a high level of interoperability. Separation of 
communities of interest is accomplished through the creation 
of logical subnets oy cryptogra phic means, by software 
control, or both. For unclassified subscribers, the 
switches provide the ability to define logical subners which 
restrict traffic to flow only among the members of rhat 
logical subnet. The number of subnets provided by the 
switches is currently limited to 16, but can be increased to 
32 or 64. 

Classified user communiries will be separated by 
IPLI subnets (like-keyed IPLIs) . Current policy limits IPLI 
separated communities of interest to 128 subscribers. 

Access control to subscriber facilities is the 

responsibility of the subscribers themselves. The network 
will assure that access of one subscriber to another is 
controlled with respect to authorized security level and 
community of interest, but will not verify that an indivi- 
dual user (person or process) has valid access rights to 

that subscriber, 

5* Per sonnel Clearances and K§^§ 

All personnel with access to switches must be 

cleared to the SECRET level due to the traffic analysis 
potential. This clearance level also applies to all 

personnel at the MCs. Personnel manning an MC for a secure 
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subr.et. must be cleared to the level of the subnet subscri- 
bers. Crypto technicians will be required for keying the 
IPLIs for each community and for link K3s. The keying 
material for each IPLI community is available only at the 
IPLI sites. The keying material for the link KGs is avail- 
able on a pairwise basis ar the switch sites based on switch 
connecti vit y. 
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